Move EnC manager implementation down to Features layer (16.3 P1)

[tmat]

Replaces legacy EnC manager implementation with a new one.

The previous implementation of the EnC manager in the debugger communicated with language services via project system coupled interfaces (IVsENCRebuildableProjectCfg*). This had many limitations, including necessity to perform IO synchronously on UI thread, lack of support for multi-targeting, necessity to make buffers readonly while application is running and for projects whose modules were not loaded to the debugee process etc.

The new architecture completely removes the dependency on Project System. The debugger communicates with language services via a MEF component. Language services export

1. IDebugStateChangeListener
   The implementation of this interface receives callbacks from the debugger when the debug state changes:

        void EnterBreakState(BreakStateKind kind);
        void ExitBreakState();
        void StartDebugging();
        void StopDebugging();

2. IEditAndContinueManagedModuleUpdateProvider

The implementation responds to the debugger's requests for updates in managed modules.
The debugger sends these requests when changes made in source files need to be applied due to a user action (e.g. "continue" in break mode, change current IP while in break mode, etc.).

Avoiding read-only buffers

Previously we made buffers read only in scenarios where we couldn't apply the change at the end of the current edit session ("continue"). This could be for multiple reasons:

1. Changing source files while the application is running
   Changes can only be applied when the debuggee is stopped.

We let the user made changes while the debuggee is running. We report a warning for these changes notifying the user that the changes are not being applied while the debugee is running.

When the debugger stops on a breakpoint in a modified source, the source won't match the one that's being executed so based on the settings the debugger may display a dialog saying so. We will follow up to improve that experience, but not going to block the change on it.

2. Changing source files of projects during edit session whose corresponding module is not loaded to the debugee
   Since the modules are not loaded we can't apply the delta at the end of the edit session (there is no module in the debugee process to apply the delta to).

We calculate the EnC deltas for all projects changed during edit session regardless of whether their modules are loaded or not. At the end of the session we apply deltas only to modules that are loaded, but we remember all the deltas we calculated for next opportunity to apply changes. Such opportunity occurs when a module is loaded while the debuggee is running. At that point the debuggee is stopped while the even is processed and we can apply all deltas that were made to the project that corresponds to the module. Note that this also handles the case where multiple instances of the same module are loaded to the debuggee (e.g. to different AppDomains or AssemblyLoadContexts). The previous design didn't account for this scenario resulting in bugs like #34253.

3. Other reasons that disallow EnC (e.g. being stopped at exception, the debuggee process not supporting EnC, etc.).

We do not block the user from making changes in the source files. Instead we report regular errors like we do for other Rude Edits. We use new APIs added to Concord to support querying for availability of EnC for specific module.

Fixes #10203.
Fixes #11656.
Fixes #18917.
Fixes #21170.
Fixes #27373.
Fixes #27735.
Fixes #29223.
Fixes #34253.
Fixes DevDiv 750649
Fixes DevDiv 551604

See also #18350.

[tmat]

@ivanbasov Would you mind signing off - the same PR as #36010, just ported to 16.3