Enable WINE_MONO_HIDETYPES by default

[madewokherd]

For now, this is only for testing purposes. This change would have to be in a major release like 7.0.0.

[madewokherd]

Fewer test failures than I expected:

2021-10-14T00:45:48.7826556Z x86.MonoTests.Microsoft.Build.BuildEngine.TargetTest:BuildProjectWithItemGroupInsideTarget
2021-10-14T00:45:48.7829407Z x86.MonoTests.Microsoft.Build.BuildEngine.TargetTest:BuildProjectWithItemGroupInsideTarget2
2021-10-14T00:45:48.7831839Z x86.MonoTests.Microsoft.Build.BuildEngine.TargetTest:ItemGroupInsideTarget_Batching
2021-10-14T00:45:48.7834023Z x86.MonoTests.Microsoft.Build.BuildEngine.TargetTest:ItemGroupInsideTarget_Condition
2021-10-14T00:45:48.7836340Z x86.MonoTests.Microsoft.Build.BuildEngine.TargetTest:ItemGroupInsideTarget_Expression_in_Metadata
2021-10-14T00:45:48.7838597Z x86.MonoTests.Microsoft.Build.BuildEngine.TargetTest:ItemGroupInsideTarget_KeepMetadata
2021-10-14T00:45:48.7840858Z x86.MonoTests.Microsoft.Build.BuildEngine.TargetTest:ItemGroupInsideTarget_ModifyMetadata
2021-10-14T00:45:48.7843112Z x86.MonoTests.Microsoft.Build.BuildEngine.TargetTest:ItemGroupInsideTarget_RemoveMetadata
2021-10-14T00:45:48.7845408Z x86.MonoTests.Microsoft.Build.BuildEngine.TargetTest:ItemGroupInsideTarget_RemoveMetadata2
2021-10-14T00:45:48.7847679Z x86.MonoTests.Microsoft.Build.BuildEngine.TargetTest:ItemGroupInsideTarget_UpdateMetadata
2021-10-14T00:45:48.7849972Z x86.MonoTests.Microsoft.Build.BuildEngine.TargetTest:PropertyGroupInsideTarget_Condition

[madewokherd]

Those tests check for Mono.Runtime and do something differently on Mono, which leads me to believe that the behavior of the library being tested hasn't changed.

[madewokherd]

OK, so, searching all code in wine-mono for this, we have:

• Mono.Cecil uses it to decide whether to read and write MDB or PDB symbols. But MDB is obsolete.
• Mono.Cecil uses it to decide where to look for mscorlib and the GAC. To support third-party code using Mono.Cecil, we must put those things in c:\windows\Microsoft.NET, though hopefully they do not need to be the full libraries. This doesn't seem to be used by us but may be used by application-packaged cecil. mdoc is similar.
• System.Web.Compilation uses it to give special treatment to MonoType. But, MonoType isn't actually used anymore, it's just there to satisfy checks for Mono. So this will never be used.
• System.Web.Util uses Mono.Runtime to get the name of the runtime.
• ikvm uses it to decide whether to use fusion.dll.CompareAssemblyIdentity. This is currently a stub in Wine. We'll need to implement it. This is used by mcs and may be used by application-packaged ikvm.
• ikvm's ModuleWriter uses it to work around some Mono mmap behavior. Unsure if this applies to us using OS dll loading.
• corefx's System.IO.Packaging.InternalRelationshipCollection checks this to work around https://www.mono-project.com/docs/faq/known-issues/urikind-relativeorabsolute/, we should ensure this behavior doesn't happen for Mono on Windows as it shouldn't be needed. WPF also has this code.
• nunit-lite uses Mono.Runtime.GetDisplayName
• nunit-lite uses Mono.Runtime.WriteStateToDisk if MONO_TEST_TELEMETRY is set in the environment
• nunit-lite uses Mono.Runtime to report Mono
• ikdasm uses it to check for Mono.Options. The .NET codepath should work fine, and we don't appear to use ikdasm.
• linker uses it to only process LoadI18nAssemblies on Mono. Anyone using it should provide their own class libraries, so this doesn't matter.
• VBNC has a check for MonoType, but the check is broken so it already doesn't detect Mono. Also, we don't use vbnc.