Revisit use of static/const/constexpr keywords on variables

[neobrain]

We currently apply different, not strictly consistent idioms of these throughout the code base. Instead of derailing PR reviews with discussions on this, let's settle for a few guidelines that should be easy to understand and apply while not introducing performance hazards.

[neobrain]

Here are some unfinished thoughts (for personal reference)

Variables with constant values:

• By default: const (global constants (constexpr?), local constants)
• Large, local mathematically constant data: static constexpr (also for class members)
• Large, global mathematically constant data: constexpr static constexpr [1]

Variables that aren't constant

• No extra keywords by default
• Global variables only used in the current file: static

Rare special cases (don't apply without knowing what you do):

• static const (one-time initialization of complex data)
• static (persisting variables, e.g. for caching)
• constexpr (compile-time programming)
• Large local data (const or non-const): Likely shouldn't live on the stack
• Large global non-const data with constant initializer: constinit
• TODO: inline constexpr?

Not covered:

• functions

Rationale:

• Make rules easy to apply consistently: For common cases, we shouldn't have a gazillion of rules. Doing something excep should require reading the fine print, and the main rules should make it obvious what's an exceptional case (e.g. by omitting the specific keywords that would be needed for exceptional cases)
• Avoid state bugs from accidental static constexpr -> static const refactors. This could happen e.g. when adding a parameter dependency to a computation and subsequently dropping constexpr for const. The could would seemingly work but you could easily forget dropping the static
• Rule for large data:
  • In functions: otherwise data gets copied to the stack each time => performance hazard
  • [1] Globally: Otherwise computed data might not get baked into the binary and instead get initialized at runtime. static is redundant, but using it allows for one fewer rule.