Had to clean up a few nullable annotations now that we are compiling
agaist `netcoreapp3.1` and hence get the full value of the framework
annotations.

This is also problematic though because there are now two places where
the compiler can see nullable attributes that are directly used by the
developer. For example `NotNullWhenAttribute`. This is both defined in
our assemblies for non-netcoreapp target frameworks and provided by the
SDK when targeting `netcoreapp3.1`.

This causes a problem for assemblies which have the following
characteristics:

1. Target `netcoreapp3.1`
1. Reference an assembly targeting `netstandard2.0` which uses our
nullable attributes definition
1. Has IVT into (2) above

These properties essentially define all of our unit test assemblies. In
that environment it's not possible to use nullable attributes in code
because the compiler can't disambiguate which definition of
`NotNullWhenAttribute` to use. This meant I had to temporarily remove a
few attributes until we can complete #40766.

Need to cancel our own `CancellationTokenSource` before invoking the
core MSBuild cancellation logic.

closes #31950

Merge remote-tracking branch 'origin/features/editorconfig-in-compiler' into merges/master-to-features/editorconfig-in-compiler

The custom assembly resolution is no longer needed in our MSBuild task
now that it has no project references and multi-targets to the important
runtimes.

This logic has actually been broken for some time now. More recent
changes revealed it's just not necessary.

Update the tasks and targets to accept actual and potential .editorconfig files and push them through to the host object.

* Fix compiler server mismatched version:
- Ensure compiler server returns correct response when providing an incorrect protocol value
- Add test to check
- Fix tests that break

* Check compiler sha as part of build server protocol:
- Add the CommitHashAttribute to the needed assemblies
- Bump the protocol version to 3
- Add a new CommitHash field to build request
- Fill out the CommitHash from the CommitHashAttribute value when creating build requests
- Check that the commitHash on a de-serialized build request matches the one compiled into the assembly
- Return a new IncorrectHash response if hashes fail to match
- Fail early on the client side if we can't get the hash

There's a problem on MacOS where the pipe name may be too long to
use as a Unix domain socket. Unfortunately, there's no way in the
version of CoreFX that we reference to override the path name
used for the named pipe. If the path is too long then the compiler
server spins infinitely trying to connect to a path.

Since we can't use our own path, the best we can do right now is
abort compiler server usage if the path would be too long. This
commit adds a check on Unix machines running on CoreCLR to
detect when the constructed path will be too long, and bail out
if this is the case.

The compiler server uses `WriteLine` to generate its output stream,
which uses the correct newlines for the current OS. When splitting
the string back into lines in the MSBuild task, though, the split
was done on Windows newlines.

Fixes #24736 by using `Environment.NewLine` instead of `\r\n` to
pass lines to MSBuild's logger, which expects errors one-per-line.

* refonly and refout on command-line and msbuild
* corresponding change to Emit API
* Metadata-only assembly use `throw null` bodies
* Can no longer produce netmodule with metadata only

This change will cause our bootstrap build to fail if a threshold of server connection failures
occur.  The threshold is chosen a bit arbitrarily as valid failures can occur.  But 15 seems like
a number to warrant an investigation.  If this produces too many false positives it will be
adjusted appropriately.