XAML hot reloading: Stop crashing Smugleaf's game (and Sloth's)

[nyeogmi]

(This draft exists in two files. The XamlX part is here.)

The hot reloading code has these four underlying problems:

• XamlX signals errors using exceptions. Apparently Rider rules that these are "user-unhandled exceptions" for some reason.
• The hot reloading change doesn't work for Robust.Client types that use internal classes.
• The hot reloading change logs hot reloading failures as INFO. (because they are expected, for those Robust.Client types)
• The hot reloading change attempts to hot reload every class once on start, in order to provide useful feedback on which classes break the hot reloader.

Two people have complained about these problems:

• @DrSmugleaf complained to me that hot reloading wasn't working for certain Robust.Client types.
• @metalgearsloth complained that hot reloading was crashing their client -- on further inspection, their client appears to be set to break on all user-unhandled exceptions.

I think we have a few non-mutually exclusive options to address this:

1. For Sloth: turn off the editor feature that is breaking on exception.
2. On startup, don't hot reload everything.
3. Explicitly exempt all Robust.Client types from the hot reloading system.
4. Make XamlX willing to handle internal classes.
5. Somehow convince Rider that these aren't "user-unhandled exceptions." I think this is because the client and engine are in separate solutions, and the engine is handling the exception: https://www.jetbrains.com/help/rider/Debugging_Exceptions.html#wy50ns_19 . Perhaps we do the compilation in a separate thread that doesn't have Content.Client in its call-stack?
6. Revert the hot reloading change completely.

If we do any of options 2, 3 and 4, we can log to WARN instead of INFO, as no failures are expected.

Note that failures will still occur in cases where people type broken code into their editor and save it -- I cannot guarantee that anybody's code will compile when the hot reloader sees it, and will continue to do my best to not take down the process when it happens.

This draft is an implementation of option 4. (Options 2 and 3 are trivial.) I personally think option 1 is the most reasonable -- ultimately I have no control of how XamlX signals errors -- but I leave the decision of what to do in the hands of the maintainers.