C#: Enable nullable environment for GodotSharp

[Repiteo]

This PR showcases a GodotSharp environment where nullability is enabled. While initially conceived as a means to centralize changes which can be branched off into standalone PRs (eg: #82980, #82983), it also showcases the consequences of trying to retrofit the concept without first undergoing significant refactoring

The biggest culprit is GodotObject, and how it's uniquely a reference type that Godot allows for nullability. While this draft explores the idea of returning GodotObject fields as nullable, I'm not convinced that makes for the best approach, because it floods almost every existing method/field with an added nullability check. It might be worth considering an approach similar to Unity Objects, where there's operator overloads & behind-the-scenes null checks to better handle null in the context of that environment. Or it could even be as simple as throwing in a bunch of [AllowNull]/[MaybeNull] annotations in the generation for object files

While the majority of areas have warnings accounted for, there's still a handful that have them. This is mainly those that I'm not entirely sure yet how to handle, or areas that feel particularly sensitive to adjustment. It's also entirely possible that many of these warnings/cases simply wouldn't be a thing with future core additions (particularly, some means of knowing if an object return value can be null). Either way, this is provided as-is for discussion and so potential areas can be cherrypicked for implementation as needed

[Repiteo]

Walked back the above two posts; I won't be adding any new functions nor expanding nullability to Godot.SourceGenerators.Sample. Both are outside the original scope of this PR and id prefer to keep things focused on ensuring a nullable environment for GodotSharp and GodotSharpEditor

[Repiteo]

As this PR is now functionally-sound entirely in isolation, I'm comfortable removing the "draft" qualifier. While it can still serve as a means of seeing how individual components would be handled, this should be just as viable to merge as-is

There's still no real answer for how best to handle GodotObject being implicitly nullable for the overwhelming majority of cases, but upon further reflection that's not really in the scope of this PR. This was about getting the existing functionality into a nullable environment, and GodotObject just so happens to be the one and only reference type that's truly nullable, and implicitly so

[dsnopek]

There's still no real answer for how best to handle GodotObject being implicitly nullable for the overwhelming majority of cases

I'm not familiar with the specifics of this PR, but this bit sounds like it might be related to this proposal that we were discussing at the GDExtension team meeting today: godotengine/godot-proposals#2241

[Repiteo]

That proposal would indeed be the solution! This PR introduces nullability in an environment that lacks those hints, so GodotObject is always treated as a nullable reference type (with very few already-guaranteed exceptions, like engine singletons), but all other reference types are never nullable (strings, StringName, NodePath, etc), just by nature of the current Godot implementations