Add cached GLOBAL_GET macros

[lawnjelly]

Instead of querying ProjectSettings fully each time, these macros first check a static local version against ProjectSettings. If the version has changed, a static local variable is updated and returned. If the version is up to date, the cached static local variable is returned.

The idea of this PR is to decrease the cost of the rather heavyweight calls to GLOBAL_GET in the codebase.

I'd already added a couple of other methods previously (the project_settings_changed signal etc) in #53296 , and that still represents the recommended way to check project settings in bulk. But this PR adds a slightly more efficient variation of the standard GLOBAL_GET, which can be fine in some circumstances and requires less boiler plate.

Notes

• If we agree on this technique I can do equivalent PR for 4.x.
• I'm a complete newbie to lambdas, and I shamelessly ripped off this approach from the SNAME macro in Godot 4, so could do with checking by someone who properly understands this voodoo and actually knows what they are doing.
• There's probably a few more places that might be worth using the FAST variation, but the PR is kept as simple as possible for bikeshedding.
• Tested memory use doesn't seem significantly different between the build before and after this PR (it is probably only a couple of Kb of static memory, unless the macros were used e.g. in a recursive situation).
• Welcome ideas on improvements for naming.
• This should actually be thread safe (providing the ProjectSettings::get() call is thread safe, which is outside the scope of this PR), despite there being no atomics etc. The only changes to _version are made in _set() which is a _THREAD_SAFE_METHOD. Reading only needs to detect a difference, even if the local version (in the macro) is mangled for 1 frame, the worst that can happen seems to a read of the project setting on 2 adjacent frames. So it doesn't seem worth making _version atomic, or having locks on _version.

[akien-mga]

We discussed this in a PR review meeting today and @reduz wasn't convinced by the approach. One mentioned issue would be that using this all the time would force keeping a global version of each setting which would stay until the process is killed and possibly cause issues for some of the Variant types involved (IIUC).

Overall we should assess what places would really benefit from something like this, otherwise the recommended approach is still to retrieve the value once in a constructor (and only update based on project settings change if/when needed on a case by case basis).