Corrects an issue where for the hour after the DST transition, the
local UTC offset was listed.  The UTC offset was the DST offset
instead of the standard time offset.

The runtime library captures this an ambiguous time.  That is
the local time that occurs twice - once in DST then once in standard
time.  If DST is an extra 1:00 a.m. offset and ends at 2:00 a.m., 1:00 a.m.
to 1:59:59.9999.... occurs twice.  First in DST then again in standard
time.

The classlibs had this incorrect - they did not consider 1:00 a.m. an
ambiguous time, and considered 2:00 a.m. ambiguous.  However it should
be reversed.  1:00 a.m. occurs twice, but 2:00 a.m. only occurs once.
The instance we would hit 2:00 a.m. DST, we instantaneous switch to
1:00 a.m. standard.

The classlibs were also not recording enough information to record
which side of DST a local time was.  When converting a time from UTC,
or using DateTime.Now an internal flag, IsAmbiguousDaylightSavingTime,
should be set if the time is an ambiguous local time that is on the
DST side of the transition.  The classlibs were calling
TimeZone.IsAmbigousTime which has a wider defintion for ambiguous
time that the IsAmbiguousDaylightSavingTime should have.  It returns
true for local times on either side of DST.  So a new method
IsAmbiguousLocalDstFromUtc was added to check this case.

The classlibs were also not checking the IsAmbiguousLocalDstFromUtc
flag when getting the UTC offset for a local time.  So a check
was inserted in two locations to correct for that.

Some tests has to be updated to reflect these new definitions of when
DST starts and ends and which times are ambiguous.  These also account
for some test changes required by cherry-picked changes to
TimeZoneInfo.cs where the corresponding test changes were not
cherry-picked.  Some of those changes where in PR's that updated to
the CoreFx TimeZoneInfo class.

All these changes have been verified against the behavior of the
.Net Framework and they match.

Fix case 1288231:
Mono: Fix incorrect UTC offset during daylight savings time transitions

Addresses an issue with jumping into DST for some time zones when the incorrect date-time offset is returned for date-time in UTC (which comes from DateTime.Now). The fix is to just check if the incoming date-time is in UTC.

Also added a set of tests for some time zones to verify jumping into DST in general.

Fixes https://github.com/mono/mono/issues/16395

Fixes https://github.com/mono/mono/issues/16742

When a datetime appears in range of [end_of_DST_period - Daylight_delta; end_of_DST_period] it's not DST and should return base offset.

Fixes #9664.

2019.4: Increase max size of localloc and localloc_imm on amd64. (#15374)

We hit the following assert when doing full AOT of some assemblies:

wrong maximal instruction length of instruction localloc (expected 96, got 99)
Assertion: should not be reached at mono\mono\mini\mini-amd64.c:6801

Turns out that that size could be hit when a couple of things happens as part
of lowering OP_LOCALLOC and OP_LOCALLOC_IMM:

sreg1 is not RAX, RCX or RDI
dreg is not RAX, RCX or RDI
cfg->param_area is bigger than 127

Fix is to increase max size of the instruction, from 96 -> 120 (same as x86).

2019.4: Add option to ignore versions when loading strong named assemblies

Reintroduce https://github.com/Unity-Technologies/mono/commit/6c41f64f25da4c12b237b6bb51765722e0dd5281#diff-0ff844e784e15d2542b71c85d2c0133e

This is so we will not get errors when resolving strong named assemblies for a version not loaded.
This option will ignore the version

Revert "Reintroduce https://github.com/Unity-Technologies/mono/commit/6c41f64f25da4c12b237b6bb51765722e0dd5281#diff-0ff844e784e15d2542b71c85d2c0133e"

This reverts commit 9d9a0eda.

Reintroduce https://github.com/Unity-Technologies/mono/commit/6c41f64f25da4c12b237b6bb51765722e0dd5281#diff-0ff844e784e15d2542b71c85d2c0133e

This is so we will not get errors when resolving strong named assemblies for a version not loaded.
This option will ignore the version

Ensure special static slots respect alignment (case 1266322)

Without proper alignment, this may lead to reference types
being stored at non-pointer aligned offsets. Among other
issues this may lead to the GC not scanning those pointers
properly.

only build 32bit osx on build server. Catalina doesn't support building 32bit so we don't want to do this by default anymore.

* Generalize commit 0c6932a9 to support LDARG{0|1|2|3}, LDLOC{0|1|2|3}, LDARGS, LDLOCS, LDARG and LDLOC instead of LDLOC and LDLOCS. Improves generated code similar to issue #60945

source: https://github.com/mono/mono/pull/12595

Re-adding whitespace to reduce diff noise and make future cherrypicks easier.

* Validate the address that came from IDE using PointerValue. The IDE can send an invalid address and it was crashing mono.

Fixes #18191
Fixes #15612
Co-authored-by: NAleksey Kliger (λgeek) <akliger@gmail.com>

Wrap create_file_to_check_memory_address in #ifndef _MSC_VER check as it's only used in that scope.

The fix for 1256569 broke a test. Reverting most of that change and breaking the CreateLocal -> WinRTFallback -> CreateLocal loop by calling GetLocalTimeZoneInfoWinRTFallback instead of accessing Local from within FindSystemTimeZoneByIdWinRTFallback fixes both issues.

Need to make sure we don't duplicate the timezone and create a new local when we already have one.

Fixing a hang that would occur when there is incorrectly set time zone data in the windows registry. (case 1256569)

[corlib] Use Environment.Platform to access the platform, rather than probing the file system (#6535)

Alternatve patch to: #6533

* mono_custom_attrs_construct_by_type allows unity to have a chance at handling the error if one arises instead of fatally asserting
* mono_unity_error_convert_to_exception allows unity to take the provided MonoError and fetch the MonoException object within to log into the editor as the exception that was thrown.

This change has associated unity changes in order to fix (case 1255935)

Fixing hang that would occur when a Debugger.Break would be triggered while we are already processing a breakpoint. (case 1254123)

Adding test for debugger hang fix to case 1254123

Added a new property to Tests class which breaks this test.

Emitting error 100 times is plenty.

This change applies a similar fix for exFAT partitions as was applied
for FAT32 partitions earlier. For exFAT partitions, the invalid inode
value seems to be 1 though.

Add System.Collections.Generic include to objects.cs

* Removing some asserts and returning err_invalid_argument with an error message when it's possible.

* if we don't find method get_ObjectIdForDebugger we try to find the property Task to continue async debug.

Cherry-picked by Alex Thibodeau with some moderate changes

* When we try to call a method to get the async_id to do an async debug and we are trying to do this in a generic method like this:

async Task<T> ExecuteAsync_Broken<T>()
 {
            await Task.Delay(2);
            return default;
  }

We need to inflate the generic type before call the method or we will get the error:  Could not execute the method because the containing type 'System.Runtime.CompilerServices.AsyncTaskMethodBuilder1[T_REF]’, is not fully instantiated.

Fixes #17549
Fixes #17569

Cherry-picked by Alex Thibodeau -- some light massaging required

* [debugger] Fixing two crashes while debugging an Android app.

-> Doing stepping into in VSM in some situation the frame saved in TLS is not synchronised with what is really been executed in the main thread. This makes the debugger-agent crashes because it tries to get variable info in some memory that is not available anymore.
	-> To fix it I forced the update of stack when CMD_THREAD_GET_FRAME_INFO is called.

-> Doing step over in Visual Studio for Windows, if you have the threads debugger window enabled, VSW calls frame_commands for each thread that is showed, and if the thread is not really_suspended it tries to get variable info from a memory that is not available anymore because the thread is not suspended yet.
	-> To fix it I don't send variable info of a frame if the thread is not really_suspended and doesn't have an async_state valid.

Cherry-picked with some light massaging by Alex Thibodeau (case 1249172)

Branch name updates for 2019.4

Same method that ldloc.s uses, which incorporates the byref test.

When we have the following sequence:

    ldloc n
    ldfld valuetype [Unity.Mathematics]Unity.Mathematics.int2 Foo::bar

and local n is a reference to value, when walking the instructions in
mono_method_to_ir, we generally try to avoid loading a whole value
type just to load one of the fields.  I believe this is an
optimization.

The test here is not quite complete, though, as we have ref valuetypes
where the object stored at the location is actually an address, in
which case we still need to treat it as we would a normal reference.

This optimization isn't present in the ldloc.n coded forms and is
written in a slightly more robust way in ldloc.s, so no changes are
necessary there.

As an alternative to this commit, we might adopt the ldloc.s test for
ldloc as well, or merge in
https://github.com/mono/mono/commit/29428d951637ff85b593ea5c9cc5d5236579906d/mono/mini/method-to-ir.c
from master which encapsulates much the same intent.

This brings us in line with GetDiskFreeSpaceExW on Windows as well as .NET Core.