[C#] Enable nullability for variant classes

[Repiteo]

Another minor update on the road to GodotSharp being nullable by default. In a similar vein to #82980, this focuses only on Variant types, but the class-equivalents instead. Still mostly small changes, but this is comparatively more involved than the structs, so it warrants its own PR

[raulsntos]

Thanks for helping annotate the codebase for nullability.

I feel like a lot of these cases shouldn't allow null. It looks like you might have just added ? to the parameters that are checked for nullability, but that doesn't necessarily mean a null value is acceptable.

I appreciate this being a separate PR, because I think it may take some time to decide the nullability of some of these parameters.

[Repiteo]

It looks like you might have just added ? to the parameters that are checked for nullability, but that doesn't necessarily mean a null value is acceptable.

Oh! Well then, that's a misconception on my end. In that case I would assume the null checks being for non-null types are for when they're called via a null-oblivious environment?

[raulsntos]

Yes or when the user intentionally ignores the warning or uses the null forgiving operator (!), the documentation reads:

Nullable reference types are a compile time feature. That means it's possible for callers to ignore warnings, intentionally use null as an argument to a method expecting a non nullable reference. Library authors should include runtime checks against null argument values.

So, nullable types can be used to document if the parameter allows null, but the implementation should still check anyway. Of course, this only applies to public API, non-public API doesn't have to check because we should be able to ensure we are not calling it wrong.

[Repiteo]

Made some expansions to GodotObject, namely the extension class, and after checking what other classes might've been affected I realized the rabbit-hole effect of this process. Now DelegateUtils.cs and ScriptManagerBridge.cs recieved minor updates to account for the new nullability checks (plus a fix in the latter that I recall we talked about at some point, but never actually put into a proper commit). If those seem out of the scope of this PR, I'll revert them

After this, I'll probably make a draft PR that just converts everything to nullable, and future PRs will simply piecemeal from that

[Repiteo]

Added null checks to the typed collection constructors taking their untyped collection equivalents, as them not being there before seems to be an oversight (_underlyingArray is assumed to never be null)

[raulsntos]

Reference types should implement IEquatable<T?>, that means NodePath should implement IEquatable<NodePath?> but right now it implements IEquatable<NodePath> (notice the missing ?).

[raulsntos]

LGTM.

[YuriSizov]

Thanks!

[YuriSizov]

Builds for the .NET version on the build server fail with these errors, which I believe are related to this PR:

modules/mono/glue/GodotSharp/GodotSharp/Core/StringName.cs(87,42): error CS0103: The name 'from' does not exist in the current context [modules/mono/glue/GodotSharp/GodotSharp/GodotSharp.csproj]
modules/mono/glue/GodotSharp/GodotSharp/Core/Array.cs(1145,42): error CS0103: The name 'from' does not exist in the current context [modules/mono/glue/GodotSharp/GodotSharp/GodotSharp.csproj]
modules/mono/glue/GodotSharp/GodotSharp/Core/Dictionary.cs(564,42): error CS0103: The name 'from' does not exist in the current context [modules/mono/glue/GodotSharp/GodotSharp/GodotSharp.csproj]
modules/mono/glue/GodotSharp/GodotSharp/Core/NodePath.cs(141,42): error CS0103: The name 'from' does not exist in the current context [modules/mono/glue/GodotSharp/GodotSharp/GodotSharp.csproj]

And also with

modules/mono/glue/GodotSharp/GodotSharp/Core/NativeInterop/ExceptionUtils.cs(244,90): error CS0103: The name 'ptr' does not exist in the current context [modules/mono/glue/GodotSharp/GodotSharp/GodotSharp.csproj]

which is related to #85975.

Fix: #86373.