Align public concept names with standard C++ naming conventions

[ipapadop]

Motivation

The library currently exposes concepts with type-style capitalization:

Deferred
AnyDeferred
HasSubexpressionTypes
CaseExpression
DefaultExpression

Standard-library concepts use lower-case names such as std::invocable, std::integral, and std::convertible_to. Lower-case names would make deferred constraints look more familiar in generic C++:

template<deferred_expression T>
void use(T&& value);

template<typename... T>
concept any_deferred = ...;

Proposed direction

Evaluate a consistent lower-case naming scheme, for example:

• Deferred → deferred_expression
• AnyDeferred → any_deferred
• HasSubexpressionTypes → has_subexpression_types
• CaseExpression → switch_case
• DefaultExpression → switch_default

The exact names should be chosen together so terminology remains coherent.

Design considerations

• These concepts are public API and may be used by downstream templates.
• Compatibility aliases are not straightforward for concepts in every use; duplicate concept definitions can provide a transition period.
• Avoid names that collide with existing functions or types.
• Decide whether domain concepts should describe syntax (has_subexpression_types) or semantic intent (deferred_expression).
• Update template parameter names that currently shadow concept names, such as packs named CaseExpression.
• Keep trait compatibility (is_deferred, is_deferred_v) independent of the concept naming decision.

Compatibility

Renaming concepts is breaking unless old concept spellings remain as compatibility definitions. A deprecation strategy may require documentation rather than compiler attributes because concepts cannot be deprecated uniformly across supported compilers.

Acceptance criteria

• A complete naming table covers every public concept.
• New names follow one documented convention.
• Old spellings either remain for a transition period or the change is scheduled for a major release.
• Traits such as is_deferred_v continue to work.
• All public documentation and examples use the chosen canonical names.
• Compile-time tests cover both canonical and compatibility spellings where applicable.
• GCC 13.3, Clang 16, and MSVC 19.44 compatibility is retained.