[xbuild] Remove ErrorTest.TestExecute1()

This was an incorrect test. Tasks can't really be used like this
especially this once since it tries to Log an error, but it hasn't been
assigned a BuildEngine yet!

Other fixes in TaskLoggingHelper expose this issue.

Merge pull request #2751 from akoeplinger/fix-msbuild-remapping

Fix msbuild remapping

First commit:
```
Revert "Do not remap framework assembly if it's version is higher than the runtime version"

It would cause issues on mobile, cause the runtime version is 2.0.5.0 there and loading
e.g. System.dll v4.0 would no longer be mapped to that version anymore after this change.
```
---
Second commit:
```
[runtime] Stop remapping higher versions of
 Microsoft.Build.Framework/Engine and remap Microsoft.Build.Utilities/Tasks
 (.v3.5)

The previous remapping was added in 725ed3f82400b1466ca17e99b85adcbde54238ca, but it didn't actually
fix the bug in https://bugzilla.xamarin.com/show_bug.cgi?id=32561.

The underlying cause of the bug is that in Mono 4.0 we removed the 2.0/3.5 profiles.
This meant that Microsoft.Build.Utilities.dll and Microsoft.Build.Utilities.v3.5.dll weren't installed
in the GAC anymore, because MSBuild 4.0 uses Microsoft.Build.Utilities.v4.0.dll, so the app failed
to load the 2.0 version of the assembly. The same applies for the .Tasks variants.

We remap earlier versions of the Microsoft.Build.Utilities/Tasks assemblies to the v4.0 version.
I've introduced another item in the AssemblyVersionMap struct which allows remapping to target a different
assembly name, because MSBuild made the questionable decision to put the version number in the assembly name.
While strictly speaking this is not what .NET is doing (it just fails there if .NET 2.0 isn't installed)
on Mono there's no way to install those older profiles anymore, so we remap them to v4.0 to keep apps working.

Newer versions of Microsoft.Build.Framework/Engine (like 12.0, 14.0) however have the same name, so we need to be
more careful here and only do a remapping to the 4.0 version if it's an earlier version (e.g. 2.0 -> 4.0).
This avoids issues with accidentally remapping 14.0 -> 4.0.

I tested the app from the bug report and it now works fine.
```

[runtime] Stop remapping higher versions of Microsoft.Build.Framework/Engine and remap Microsoft.Build.Utilities/Tasks (.v3.5)

The previous remapping was added in 725ed3f82400b1466ca17e99b85adcbde54238ca, but it didn't actually
fix the bug in https://bugzilla.xamarin.com/show_bug.cgi?id=32561.

The underlying cause of the bug is that in Mono 4.0 we removed the 2.0/3.5 profiles.
This meant that Microsoft.Build.Utilities.dll and Microsoft.Build.Utilities.v3.5.dll weren't installed
in the GAC anymore, because MSBuild 4.0 uses Microsoft.Build.Utilities.v4.0.dll, so the app failed
to load the 2.0 version of the assembly. The same applies for the .Tasks variants.

We remap earlier versions of the Microsoft.Build.Utilities/Tasks assemblies to the v4.0 version.
I've introduced another item in the AssemblyVersionMap struct which allows remapping to target a different
assembly name, because MSBuild made the questionable decision to put the version number in the assembly name.
While strictly speaking this is not what .NET is doing (it just fails there if .NET 2.0 isn't installed)
on Mono there's no way to install those older profiles anymore, so we remap them to v4.0 to keep apps working.

Newer versions of Microsoft.Build.Framework/Engine (like 12.0, 14.0) however have the same name, so we need to be
more careful here and only do a remapping to the 4.0 version if it's an earlier version (e.g. 2.0 -> 4.0).
This avoids issues with accidentally remapping 14.0 -> 4.0.

I tested the app from the bug report and it now works fine.

[System] Bump CTS timeout in BlockingCollectionTests

Saw a few failures on Jenkins on the slower ARM machines over the last days:

```
) MonoTests.System.Collections.Concurrent.BlockingCollectionTests.AddAnyCancellable : System.OperationCanceledException : The operation was canceled.
at System.Collections.Concurrent.BlockingCollection`1[T].TryAddToAnyCore (System.Collections.Concurrent.BlockingCollection`1[] collections, System.Collections.Concurrent.T item, Int32 millisecondsTimeout, CancellationToken externalCancellationToken) [0x00092] in /media/ssd/jenkins/workspace/test-mono-mainline/label/debian-armel/external/referencesource/System/sys/system/collections/concurrent/BlockingCollection.cs:1041
at System.Collections.Concurrent.BlockingCollection`1[T].TryAddToAny (System.Collections.Concurrent.BlockingCollection`1[] collections, System.Collections.Concurrent.T item, Int32 millisecondsTimeout, CancellationToken cancellationToken) [0x00006] in /media/ssd/jenkins/workspace/test-mono-mainline/label/debian-armel/external/referencesource/System/sys/system/collections/concurrent/BlockingCollection.cs:971
at System.Collections.Concurrent.BlockingCollection`1[T].AddToAny (System.Collections.Concurrent.BlockingCollection`1[] collections, System.Collections.Concurrent.T item, CancellationToken cancellationToken) <0x4421bf18 + 0x0002b> in <filename unknown>:0
at MonoTests.System.Collections.Concurrent.BlockingCollectionTests.AddAnyCancellable () [0x00031] in /media/ssd/jenkins/workspace/test-mono-mainline/label/debian-armel/mcs/class/System/Test/System.Collections.Concurrent/BlockingCollectionTests.cs:276
at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0003d] in /media/ssd/jenkins/workspace/test-mono-mainline/label/debian-armel/mcs/class/corlib/System.Reflection/StrongNameKeyPair.cs:103
```

100ms is likely just too short, bumping it.

Merge pull request #2749 from BrzVlad/fix-suspend-deadlock

[runtime] Fix deadlock while unwinding the stack of suspended thread

A suspended thread, in non-coop case, can be holding runtime locks. When the suspender tries to unwind the stack for this thread, it might require taking of runtime locks (ex. in aot case we might search for the jit info in the aot image and then register it, which requires the domain lock). Mark the suspender thread as running in async context while it unwinds other threads.

Revert "Do not remap framework assembly if it's version is higher than the runtime version"

This reverts commit 100bd760a46811121b4b47ebba941d4fb98486ab.

It would cause issues on mobile, cause the runtime version is 2.0.5.0 there and loading e.g. System.dll v4.0 would
no longer be mapped to that version anymore after this change.

[runtime] Fix monodroid build

Merge pull request #2744 from akoeplinger/convert-fixes

[corlib] Fix Convert.ToUInt32 not throwing OverflowException with a too large number

[mcs] Codegen update for specialized struct initialization with awaited element initializer. Fixes #39459

[tests] Add test for assembly remapping change from 100bd760a46811121b4b47ebba941d4fb98486ab

Testing for the remap message via grep isn't ideal, a better way to verify the assembly
version would be to check asm.GetName().Version, but unfortunately in the test environment
when MONO_PATH is set the assembly loading always fallsback to a simple file name matching
in the directory so we end up with the wrong (v4.0) assembly in that case.

Merge pull request #2733 from ludovic-henry/fix-mono_cpu_count

[utils] Make distinction between configured and online CPU count

[jit] Add a separate header file for llvm-jit.cpp.

[corlib] Fix Convert.ToUInt32 not throwing OverflowException with a too large number

This was revealed by the CoreCLR tests/src/CoreMangLib/cti/system/convert/converttouint3219.exe test.

When we tried to convert a number larger than UInt32.MaxValue (in this case 4933891728) we would cast
the intermediate result to uint which overflows and makes the end result smaller which means we don't throw.

Storing the intermediate result in a long before checking for the correct range fixes this.

Added a few additional tests that I felt were missing and/or only present for other Convert.* methods.
I found two more cases that don't throw OverflowException but fixing it looked more involved so I punted
and just ignored them with a FIXME for now.

[utils] Make distinction between ARM platforms for CPU count

ARM platform tends to try very hard to save power by switching off CPUs. This could lead to inconsistencies in the value returned by mono_cpu_count

Recap from Alexander Köplinger <alex.koeplinger@outlook.com>:

When we merged the change from PR #2722, we started seeing random failures on ARM in the MonoTests.System.Threading.ThreadPoolTests.SetAndGetMaxThreads and MonoTests.System.Threading.ManualResetEventSlimTests.Constructor_Defaults tests. Both of those tests are dealing with Environment.ProcessorCount to verify some implementation details.

It turns out that on the Jetson TK1 board we use on public Jenkins and on ARM kernels in general, the value returned by sched_getaffinity (or _SC_NPROCESSORS_ONLN) doesn't contain CPUs/cores that are powered off for power saving reasons. This is contrary to what happens on x86, where even cores in deep-sleep state are returned [1], [2]. This means that we would get a processor count of 1 at one point in time and a higher value when load increases later on as the system wakes CPUs.

Various runtime pieces like the threadpool and also user code however relies on the value returned by Environment.ProcessorCount e.g. for deciding how many parallel tasks to start, thereby limiting the performance when that code thinks we only have one CPU.

Talking to a few people, this was the reason why we changed to _SC_NPROCESSORS_CONF in https://github.com/mono/mono/pull/1688 and why we added a special case for Android in https://github.com/mono/mono/commit/de3addcde5bf875dcd43d3e2c6536d61871e7675 to get the "real" number of processors in the system.

Because of those issues Android/Dalvik also switched from _ONLN to _SC_NPROCESSORS_CONF for the Java API Runtime.availableProcessors() too [3], citing:
> Traditionally this returned the number currently online,
but many mobile devices are able to take unused cores offline to
save power, so releases newer than Android 4.2 (Jelly Bean) return the maximum number of
cores that could be made available if there were no power or heat
constraints.

The problem with sticking to _SC_NPROCESSORS_CONF however is that it breaks down in constrained environments like Docker or with an explicit CPU affinity set by the Linux `taskset` command, They'd get a higher CPU count than can be used, start more threads etc. which results in unnecessary context switches and overloaded systems. That's why we need to respect sched_getaffinity.

So while in an ideal world we would be able to rely on sched_getaffinity/_SC_NPROCESSORS_ONLN to return the number of theoretically available CPUs regardless of power saving measures everywhere, we can't do this on ARM.

I think the pragmatic solution is the following:
* use sched_getaffinity (+ fallback to _SC_NPROCESSORS_ONLN in case of error) on x86. This ensures we're inline with what OpenJDK [4] and CoreCLR [5] do
* use _SC_NPROCESSORS_CONF exclusively on ARM (I think we could eventually even get rid of the PLATFORM_ANDROID special case)

Thoughts?

Helpful links:

[1] https://sourceware.org/ml/libc-alpha/2013-07/msg00383.html
[2] https://lists.01.org/pipermail/powertop/2012-September/000433.html
[3] https://android.googlesource.com/platform/libcore/+/750dc634e56c58d1d04f6a138734ac2b772900b5%5E1..750dc634e56c58d1d04f6a138734ac2b772900b5/
[4] https://bugs.openjdk.java.net/browse/JDK-6515172
[5] https://github.com/dotnet/coreclr/blob/7058273693db2555f127ce16e6b0c5b40fb04867/src/pal/src/misc/sysinfo.cpp#L148

[build] Define HOST_* architecture

Merge pull request #2732 from radical/asm_remap

Do not remap framework assembly if it's version is higher than the ru…

…ntime version

Currently, assemblies like Microsoft.Build.Framework and
Microsoft.Build.Engine get remapped to the current runtime version, at
load time. This means that if an assembly references the above
assemblies with a version like `14.1.0.0`, then that would get remapped
to `4.0.0.0`. This is incorrect behavior and breaks msbuild. Instead,
now we do the remapping only if the requested version is lower than the
runtime version.

Merge pull request #2741 from akoeplinger/acceptance-tests-split

A few improvements to acceptance-tests

Merge pull request #2743 from qmfrederik/fixes/complete-eventsource-3

System.Diagnostics.Tracing: Add EventListener and related classes

[xbuild] Remove explicit warning level set when csproj does not have it and leave the default to compiler

[runtime] Fix deadlock while unwinding the stack of suspended thread

A suspended thread, in non-coop case, can be holding runtime locks. When the suspender tries to unwind the stack for this thread, it might require taking of runtime locks (ex. in aot case we might search for the jit info in the aot image and then register it, which requires the domain lock). Mark the suspender thread as running in async context while it unwinds other threads.

Do not remap framework assembly if it's version is higher than the runtime version

Currently, assemblies like Microsoft.Build.Framework and
Microsoft.Build.Engine get remapped to the current runtime version, at
load time. This means that if an assembly references the above
assemblies with a version like `14.1.0.0`, then that would get remapped
to `4.0.0.0`. This is incorrect behavior and breaks msbuild. Instead,
now we do the remapping only if the requested version is lower than the
runtime version.

@akoplinger: This will actually impact xbuild too right now because
we're defaulting to xbuild 14.0 in Mono 4.4 now so we'd see messages
like Mono: The request to load the assembly Microsoft.Build.Framework
v14.0.0.0 was remapped to v4.0.0.0 in the assembly loading log, which
will break in very subtle ways.

Bump ikdasm

System.Diagnostics.Tracing: Add EventListener and related classes

Merge pull request #2742 from mono/revert-2738-fixes/complete-eventsource-2

Revert "Add EventListener and EventListenerEventArgs to Mono"

Revert "Add EventListener and EventListenerEventArgs to Mono"

[acceptance-tests] Better description in readme

Merge pull request #2738 from qmfrederik/fixes/complete-eventsource-2

Add EventListener and EventListenerEventArgs to Mono

[acceptance-tests] Stop symlinking System.Console.dll facade

It should no longer be required after 6e81edfa241bedbb3971ca1e7aece82f31de54c1.

[acceptance-tests] Split the test suites out of Makefile.am into own files

[mcs] nameof operator can use static member. Fixes #39455

[llvm] Add beginnings of JIT support for LLVM > 3.9.

[acceptance-tests] Move git "submodules" to acceptance-tests/external instead of next to Mono repo

A few people told me it's surprising that acceptance-tests checks out repos into <mono repo>/../
and it can cause unwanted changes when a repo with the same name already exists there.

While this structure is used in several internal repos I agree for Mono it's better to keep
everything inside the repo itself.

[aot] Fix a buffer overflow in the statistics code.

[runtime] Remove some unused code.

Remove #if NET_4_6

Remove conditional compilation statement as per PR feedback

Merge pull request #2736 from xmcclure/more-trampolines

Increase default number of aot-compile trampolines

The current defaults are not enough to successfully run
`make fullaotcheck` in mono/mini

Merge pull request #2735 from xmcclure/early-lookup-addr

Early ICALL_ADDR lookup on pinvoke to fix checked-build assert

The pinvoke implementation in the failure case was creating a managed
exception object while in blocking mode, a rules violation. This patch
puts a redundant lookup early so that any exceptions occur before
blocking mode is entered. (The "real" lookup is unchanged because the
current pattern is optimized well by the JIT.)

Merge pull request #2731 from Phyyl/master

Remove throw statement in IPAddress.TryParse

In Microsoft's implementation, no exceptions are thrown in this particular method. See here for details: http://referencesource.microsoft.com/#System/net/System/Net/IPAddress.cs,54a3a3f536d5a22c

Merge pull request #2674 from lambdageek/dev/monoerror-mono_field_get_value_object

Use MonoError for mono_field_get_value_object

Mark it external only.  Runtime should use mono_field_get_value_object_checked.

Increase default number of aot-compile trampolines

The current defaults are not enough to successfully run
`make fullaotcheck` in mono/mini

Merge pull request #2718 from lambdageek/dev/monoerror-sre

[System.Reflection.Emit] Use MonoError in static functions

Fix an assert in checked-build GC mode

The pinvoke implementation in the failure case was creating a managed
exception object while in blocking mode, a rules violation. This patch
puts a redundant lookup early so that any exceptions occur before
blocking mode is entered. (The "real" lookup is unchanged because the
current pattern is optimized well by the JIT.)

[runtime] Fix the support for coop in managed-native wrappers by finishing blocking inside the try clause before converting the result, and only unblocking in the finally clause if we didn't unblock in the try clause.

Added null check in IPAddress.Parse
This check was previously handled in the IPAddress.TryParse method but, but the latter never throws anymore

Merge branch 'master'

[SRE] MonoError in mono_image_emit_manifest

[SRE] MonoError in mono_image_fill_export_table

[SRE] MonoError in mono_image_get_array_token

[SRE] MonoError in mono_image_get_sighelper_token

[SRE] MonoError in mono_image_get_generic_field_token

[SRE] MonoError in add_custom_modifiers

[SRE] MonoError in create_generic_typespec

[SRE] MonoError in mono_image_get_field_on_inst_token

[SRE] MonoError in encode_constraints

[SRE] MonoError in mono_image_get_event_info

[SRE] MonoError in property_encode_signature

[SRE] MonoError in mono_image_get_field_info

[SRE] MonoError in encode_marshal_blob

[SRE] MonoError in field_encode_signature

[SRE] MonoError in method_encode_clauses

[SRE] MonoError in encode_locals

[SRE] MonoError in encode_reflection_type and encode_custom_modifiers

Merge pull request #2706 from ludovic-henry/fix-unhandledexception

[runtime] Set exit code on unhandled exception even if a managed handler is present

In case we would add a AppDomain.CurrentDomain.UnhandledException callback, we would not exit the VM in case of unhandled exception.
This goes against the expected behaviour, as we should indeed call these managed callbacks in all cases, but they should not stop the VM from exiting.

Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=39077

Merge pull request #2634 from ludovic-henry/coop-fix-managed-to-native

[coop] Fix managed-to-native wrapper

[runtime] Use MonoError in mono_field_get_value_object

Mark it external only.  Runtime should use mono_field_get_value_object_checked.

Embedded API. Fix method signature match failure for generic types with multiple type parameters.

Details are on the list.
http://mono.1490590.n4.nabble.com/Re-Embedded-API-ctor-method-signature-query-mono-td4667551.html

Robert Jordan said:

It looks like a bug in mono_method_desc_new ():

https://github.com/mono/mono/blob/master/mono/metadata/debug-helpers.c#L378

The function is treating

.ctor(System.Func`2<string, string>)

like a method with 2 arguments:

arg0 = System.Func`2<string
arg1 = string>

This is obviously wrong :)

The function is then storing the (wrong) argument count
for optimization purposes, and the comparison of methods
is starting to fail.

Merge pull request #2707 from lambdageek/dev/monoerror-mono_image_load_module_dynamic

[sre] Propagate MonoError in mono_image_load_module_dynamic

Updated TryParse_IpString_Null for IPAddress tests

Now reflects the new behaviour in IPAddress class, not throwing any exceptions in the TryParse method

Remove throw statement in IPAddress.TryParse

In Microsoft's implementation, no exceptions are thrown in this particular method. See here for details: http://referencesource.microsoft.com/#System/net/System/Net/IPAddress.cs,54a3a3f536d5a22c

[mcs] Fixes codegen for lifted null bitwise operators with constant left side of null value

[tests] Add unhandled exception tests with AppDomain.UnhandledException managed handler

[runtime] Set exit code on unhandled exception even if a managed handler is present

In case we would add a AppDomain.CurrentDomain.UnhandledException callback, we would not exit the VM in case of unhandled exception.
This goes against the expected behaviour, as we should indeed call these managed callbacks in all cases, but they should not stop the VM from exiting.

Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=39077

Merge pull request #2708 from lambdageek/dev/monoerror-assorted-get_type

[reflection] MonoError for mono_reflection_{get_type_with_rootimage,type_from_name}

Merge pull request #2668 from lambdageek/dev/monoerror-mono_security

[runtime] MonoError cleanup in mono-security.c

Some easy MonoError cleanup in mono-security.c: use set_pending_exception, don't raise in helper functions, free memory on errors.

Merge pull request #2670 from lambdageek/dev/monoerror-mono_runtime_object_init

[runtime] Use MonoError in mono_runtime_object_init

Mark mono_runtime_object_init checked external only.  Runtime should use mono_runtime_object_init_checked.

Merge pull request #2687 from lambdageek/dev/monoerror-mono_param_get_objects_internal

[reflection] Use MonoError in mono_param_get_objects

[runtime] Wrap mono_prepare_blocking and mono_finish_blocking in try { ... } finally { ... } clause

This is to guarantee that even in the case an exception is thrown between both calls, we switch back and forth correctly from RUNNING to BLOCKING state.

[runtime] Fix the emission of CEE_MONO_VTADDR opcodes, they need to be emitted right after native calls.

[jit] Add a new ICALL_ADDR_CALL patch type which is only used on calls, since ICALL_ADDR might be used without a call.

[mcs] Null conditional operator is never suppose to work with await according to current C# standard. Fixes #39266

[reflection] Fix mono_reflection_type_get_handle when
DISABLE_REFLECTION_EMIT is set

Fixup of 20a111a215c2ad93ab77068d2e81e21c886b9846

[mcs] Remove test as it cannot reliably depend on process shutdown

Merge pull request #2727 from akoeplinger/fix-system-testports

[System] Fix more hardcoded test ports

A test failed on Jenkins today with "address already in use".
Opportunistically replaced a few more hardcoded test ports to avoid failures in the future.

@monojenkins merge

[System/ServiceModel] Fix more hardcoded test ports

A test failed on Jenkins today with "address already in use".
Opportunistically replaced a few more hardcoded test ports to avoid failures in the future.

[mcs] All returns with values from async block with finally need to be captured. Fixes #39153

[corlib] Enable the shim __ComObject for other profiles than mobile_static too

Otherwise they crash in a similar way during verification tests.

[System] Switch DNS tests to a more stable domain/IP

info.diku.dk stopped resolving today. Use Google's public DNS server instead which should be much more stable.

[runtime] Compile arch before utils when INSTALL_MONOTOUCH is enabled

We'd run into an error before:

```
In file included from ../../mono/utils/mono-context.h:234:0,
                 from ../../mono/utils/mono-stack-unwinding.h:10,
                 from ../../mono/utils/mono-threads.h:14,
                 from mono-mmap.c:36:
../../mono/arch/arm/arm-codegen.h:936:41: fatal error: mono/arch/arm/arm_dpimacros.h: No such file or directory
```

This was done for the other cases in 637ee7cbaa03a1f576230eb8601c0c4fa7f93b36, but not when the monotouch
special case was added in cf754cdb634f2bdd5bc959cec66145372c301fba.

Merge pull request #2714 from lambdageek/dev/monoerror-mono_reflection_type_get_handle

[reflection] MonoError for mono_reflection_type_get_handle

`mono_reflection_type_get_handle` is really a kind of normalization procedure that synthesizes real `MonoType`s from reflection's derived types such as `System.Reflection.Emit.ArrayType, ByRefType`, etc.  So we call it all over the place in System.Reflection.Emit runtime code.

That would all be fine, except that users are allowed to subclass `System.Type`, so we have to call the `UnderlyingSystemType()` method to get a real type.  Which means that an override can throw.  Which in coop mode means we have to thread around a `MonoError`.  So that's why this code is uglier.

But really this code is doing a lot of type inspection and high-level work that we should figure out how to migrate to managed.

[bcl] Ensure all .sources files have newline at the end

It causes an issue with gensources.sh when using #include on Linux otherwise.

[reflection] MonoError for mono_reflection_type_get_handle

Merge pull request #2704 from BrzVlad/fix-monitor-abort

[runtime] Fix monitor abort

Fix filename casing in mobile_System.Data.dll.sources

It broke on Linux.

Merge pull request #2722 from ludovic-henry/fix-39279-docker-cpu-count

[utils] Get processor count from scheduler affinity if available

In case the user has set a scheduler CPU affinity, we should use it as the number of available CPU for the runtime. This is particularly important on docket which uses cgroups that set the container a cpu affinity, and by not using that, the runtime report the total number of CPU the machine has, and not the number of CPU the container has.

Fixes bug https://bugzilla.xamarin.com/show_bug.cgi?id=39279

Merge pull request #2700 from akoeplinger/monotouch-mobile-static

Enable building of monotouch/xammac profiles without mono-extensions and expose mobile_static in configure.ac

Relies on https://github.com/xamarin/mono-extensions/pull/17

This enables us to compile the monotouch, xammac and mobile_static profiles on public Jenkins without mono-extensions.

Merge pull request #2723 from akoeplinger/fix-decimal-test-culture

[corlib] Fix three decimal tests to not rely on current culture for formatting

They'd fail on cultures where "." is not the decimal separator before.

I've also reenabled them on mobile cause the workaround for #27269 is no longer necessary since all bots are now on Mono 4.0+.

@monojenkins merge

Merge pull request #2719 from kumpera/aot_cctor_encoding_in_method_info

[runtime] Explicitly encode the need of running a cctor on method infos.

Add a shim __ComObject class to the mobile_static build

We need this because when the runtime is built without --enable-minimal=com the runtime crashes
when trying to AOT because it tries to find the __ComObject (even though nothing in mobile_static
actually uses COM). With this shim we can AOT the mobile_static assemblies even with a "normal"
runtime.

[corlib] Fix three decimal tests to not rely on current culture for formatting

They'd fail on cultures where "." is not the decimal separator before.

I've also reenabled them on mobile cause the workaround for #27269 is no longer necessary since all bots are now on Mono 4.0+.

[corlib] Fixes build to using correct build profile dependency