[LeGo] add support for local variables

[Try]

This PR introduces api to work with local variables in form of

ZKAPI void DaedalusSymbol::set_local_variables_enable(bool enable) noexcept;
[[nodiscard]] ZKAPI bool DaedalusSymbol::has_local_variables_enabled() const noexcept;

set_local_variables_enable is intended to be called from local() call override in LeGo based mod.
Since engine has to wait for local() call, it mean on very first invocation we wont know for sure, if particular function has intent to use local-variables.

During runtime, if function annotated with has_local_variables_enabled, is called:

• if no recursion - nop. No need to stash anything until recursion is actually happens. This also align well with how local() used.
• if recursion - old values of local-variables are stashed to stack, and function-call parameters are shifted accordingly.

C++20 update
Since work with local variables is on critical path (frame-function in lego, timers and anim8-animations), performance is important. For that sake have had to use std::span for find_locals_for_function, as well as for find_parameters_for_function.

I hope C++20 is fine (and minor api break) - it's 5 years old already and should be widely supported.

[lmichaelis]

Heyo, thanks for the PR. I immediately noticed that you made a breaking change by (a) altering the return type of find_parameters_for_function and (b) to do so switching to C++20. Why exactly is this necessary?

I ask because switching to C++20 might be a non-trivial change for downstream users of ZenKit, so I'd like to avoid it if reasonably possible. Also, I would like to avoid breaking existing APIs without warning.

[Try]

Why exactly is this necessary?

Yeah, some CoM/LeGo scripts, that are now available are on critical path. One of those would be _FF_Hook running every frame - using std::vector, instead of std::span drops performance to about 40 fps. With std::span - reaching VSync limit, without issues.

I ask because switching to C++20

It's 5 yeas old standard...

[lmichaelis]

That performance increase is indeed very compelling. I'll check C++20 against the C-wrapper at least, before just enabling it.

You're right, C++20 is an old standard by now but a lot of ZenKit still uses the old C++17-style SFINAE patterns and such, so there will be some more clean up to do after I upgrade to it :) That's probably a good thing though