Provide a solid solution to help C# developers against "ALC unload failure"

[Delsin-Yu]

Describe the project you are working on

The usability of the .Net (Aka mono, Aka GodotSharp) module of the Godot Engine.

Describe the problem or limitation you are having in your project

Most, if not all Godot 4 .Net Developers will at least access the godotengine/godot#78513 issue once during their development; however, it is evident that the troubleshooting guidelines provided in the issue message has gone way beyond the skill level of the average developers, which mean they neither do not have enough skills to execute the steps nor they can understand the tooling (WinDbg, LLDB, etc.).

This issue can also happen in the future for the godot-dotnet module, so it is still a concern regardless of whether we deprecate the mono module, so it's not about making improvements on a partially maintain-only module.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Several approaches exist, each capable of addressing the problem to some extent. I will rank them based on their effectiveness.

1. Implement reloading of the mono module: While the ALC unload failure disables the mono module, the developer can reload the current project through Project/Reload Current Project. If we find a way to uplift that reloading behavior to only the mono module, we can do a module reload when the ALC reload fails, making it less disruptive.

2. Adds a Roslyn Analyzer to the Godot.Net Sdk, scans, and warns the user of any code that may lead to unloading failure.

3. Write beginner-friendly, detailed, step-by-step documentation to guide the developers through troubleshooting the unloading failure and attach it to the messages in .NET: Failed to unload assemblies. Please check <this issue> for more information. godot#78513.

If this enhancement will not be used often, can it be worked around with a few lines of script?

A few lines of the script cannot achieve the abovementioned universal solutions.
This is about the usability of the .Net part, and almost all .Net developers can encounter this; the existing solution requires senior .Net developers to be involved and create highly customized partial fixes on a per-project basis.

Is there a reason why this should be core and not an add-on in the asset library?

This is about the usability of the .Net part; moving it out from the core is not applicable in this context.