Remove env.get logic from defaults

[Repiteo]

After some local tests, it turns out these never worked in practice. They seemed to work, as the vast majority had simple fallbacks that were able to function identically. However, use_hot_reload tried to use logic from another container entirely; because that value always defaulted to template_debug, the conditional always passed & use_hot_reload was always enabled if no commandline value was specified

The majority of changes in this PR are removing the env.get logic outright, as every other case can substitute the previous fallback value as the default & the end result is functionally identical. use_hot_reload now has a default value of None, meaning it doesn't add any environment option; as such, an explicit assignment is handled before the very first use-case. This was achieved by porting over the expected logic of the previous default value

The only other change was adjusting the compiledb environment check from the env.get function to the dictionary equivalent. This is because I believe we should be using env.get only in scenarios where a value might be null. Otherwise, the fallback value used is redundant, as an explicit bool is guaranteed

EDIT: Fixes #1297

[Repiteo]

A few additions:

• Implement same revamped env.get logic to is_msvc
• Slightly change order of disable_exceptions check to ensure that msvc has a chance to be properly evaluated, instead of always defaulting to False

Both serve to fix #1297.

[dsnopek]

Thanks!

Hm. The env.get()s are there in order to support code like:

env = Environment()
env['disable_exceptions'] = False
Export('env')

SConscript("godot-cpp/SConstruct")

So that the author of a GDExtension can change what the defaults are in their case.

With this PR, how would you accomplish the same thing?

Also, this will need a rebase after PR #1299 in order for tests to pass.

[Repiteo]

That's interesting… I was testing with launch arguments before, but that seems to handle differently than assigning in Python then porting to an exported command. Not sure if the same behavior applies to the main repo, I'll have to test that sometime today Wait so, this all also means that any options in the misc subfiles will need this as well? That feels off

Either way, I suppose this was a bit of a misguided PR. There's still things about it that fix bugs that I want to get committed, but I'll just put those in a separate PR so I can untangle this in its own right

[Repiteo]

Closing this now-draft PR. The core issues have been addressed & some initial assumptions were misinformed. I still want to explore alternatives to the current env.get implementations, but removing them outright without further action isn't the play