EnC support for project level changes

[tmat]

Implements support for project level changes. Currently handled changes are

1. parse options, compilation options and other project properties
2. metadata references

More work in Roslyn is needed to fully support adding project references and changing manifest resources.

Change in option/project property may either be
a) rude edit, if it affects compilation of the delta in such a way that we can't reasonably handle (assembly name change), or it would create significant inconsistencies between updated code and unchanged code (e.g. preprocessor symbols, language version, etc.)
b) insignificant to EnC/Hot Reload (e.g. XML doc comments settings, changing assembly signing that doesn't change assembly identity)
c) significant but can be handled consistently in most cases (e.g. adding global usings, allow unsafe code, etc.)

Some changes might be significant but only take effect when the app is restarted -- e.g. changing entry point. We report "no-effect" warning for such cases, which causes auto-restart if enabled and does not block the session.

Our general guiding principles for EnC changes are
i) all source code should match the IL being executed in the app
ii) we only recompile and update changed code.
We even allow unchanged code to be semantically incorrect (contain errors). E.g. when a method changes signature we do not update all the call sites. They are left to call the previous method version which throws at runtime. Semantic error is reported at these call sites at design time.

Changing e.g. preprocessor symbols is categorized as a rude edit. We could apply the new symbols on the changed code while unchanged code would keep old semantics (according to [ii]). However, that violates [i] since the unchanged source code might now behave differently (e.g. you'd see statements being executed that are in "false" branch of ifdef).

Changing global usings is allowed. While it is possible that changing global using leads to confusion in some cases, these are rather rare. E.g. an extension method is called in unchanged code that resolves to a different extension method after the global usings are changed that is also semantically correct at the call site. When stepping through the code you'd end up in the old extension method, which might be surprising. This is however also possible already with changing using directives in the source file and we haven't seen any negative feedback.

In future, some changes in category [a] could be reclassified if we implement mitigations for the inconsistencies they cause. E.g. we could report warnings for all affected code whose semantics changed.

Implements #78921

[tmat]

@DustinCampbell ptal

[tmat]

@dotnet/roslyn-compiler for small changes to Features parse options.

[jaredpar]

Reviewed compiler changes

[jaredpar]

@RikkiGibson, @333fred PTAL at compiler changes. Fairly small