Many call operators (`operator()`) can be `static` when `defined(__cpp_static_call_operator)`

[CaseyCarter]

Clang 16 supports static operator() and defines __cpp_static_call_operator in all of our supported language modes, with a suppressible warning "before" C++23. (MSVC will eventually provide similar support in all language modes.) Static and non-static operator() have different mangled names, so we can simultaneously support both even in different TUs linked together. We need to audit our declarations of operator() and decide which can be declared static.

I think we'll want to do this by adding a couple of macro definitions:

1. a macro that expands to static when defined(__cpp_static_call_operator) and an empty string otherwise, and
2. a macro that expands to an empty string when defined(__cpp_static_call_operator) and 'const' otherwise.

We can then change the pertinent operator() declarations from e.g.:

constexpr int operator()(int x) const {
    return x + 1;
}

to

_FIRSTMACRO constexpr int operator()(int x) _SECONDMACRO {
    return x + 1;
}

I've started to prototype this in d85b96c; feel free to use that as a starting point. (I'm not fond of the names I chose for the macros, feel free to change them.)

[StephanTLavavej]

We talked about this at the weekly maintainer meeting; we like _STATIC_CALL_OPERATOR and want to use _CONST_CALL_OPERATOR because it puts the keyword first and the context second, which is pleasingly symmetric, and consistent with precedent like _NODISCARD_CTOR. It's a call operator no matter what, and then the centralized macro definitions will decide what kind of call operator it's going to be today.