`const fun` And Compile-Time Computation

Order

Recommended Issue order: 6.

Introduce compile-time executable functions for use in const definitions, where predicates, const generic arguments, and const if.

Example direction:

const fun is_power_of_two(value: u32) -> bool {
  ...
}

fun foo<const N: u32>() where is_power_of_two(N) {
  ...
}

Prerequisites:

Constant Generic Parameters, for const values in generic signatures and mangling.
Existing const predicates and const if.

Unblocks:

Full Enhanced Tuple Types, especially recursive tuple_element and const arithmetic over tuple indexes.
More expressive type/const constraints.

In scope:

const fun declaration syntax.
A restricted compile-time evaluator.
Deterministic, side-effect-free execution.
Scalar return values initially: bool, integers, and string if needed.
Calls from const definitions, where predicates, and const if.
Runtime calls from non-const contexts. In that mode, const fun behaves like a normal fun; const means compile-time capable, not compile-time only.
Recursion and loop limits with explicit diagnostics.
Function body execution should reuse the STUPID interpreter through a restricted const runner; the type checker owns const-safety checks and scalar value marshalling, not a second evaluator.

Out of scope:

const fun can compute bool/integer scalar values.
where const_fun<T>() or where const_fun(N) evaluates during type checking.
Non-terminating or over-limit compile-time execution reports a deterministic error.
Non-const functions cannot be called from const contexts.
Non-const runtime calls such as val bar = foo(x) are allowed when foo is a const fun.
Compile-time evaluator has tests for branching, loops, recursion limit, and invalid side effects.