Properly preserve VPF registers in iOS. Fixes #17793.
[arm] Use d0/d1 as fp scratch regs on non-hard float platforms. Hopefully fixes #17597.
ARM: Back up VFP scratch registers before using them on hard float.

This is because d0-d7 are argument registers and d8-d15 are
preserved registers - we can't use any of them as scratch
registers without restoring their previous values.
ARM: Handle large offsets in emit_float_args ().
ARM: Emit shorter floating point load/store sequences when possible.
[runtime] Add two variants of mono_gc_bzero and mono_gc_memmove. They better convey the behavior we need.

After reviewing all usage of mono_gc_bzero and mono_gc_memmove, I found that there are two usage patterns
we care for:

1)Aligned pointer, any size, have managed pointers.
This happens when directly dealing with managed objects like when cloning of boxing.
On this case, all pointers MUST be aligned.

2)Maybe aligned pointer, any size, might have managed pointers.
This happens for functions dealing with structs, specially around boxing and unboxing them.
Our data layout code ensures that structs with managed layout are aligned to at least a word.
This means that if the pointer is unaligned, no managed pointer can exists in the memory range
been processed.

Given those two scenarios, lets introduce two variants that enforce those constrains.

_aligned:
Pointers must be aligned, ensures atomicity of word copies;

_atomic:
If pointers are aligned, works like _aligned, otherwise it inherits the behavior of the
system memmove&memset.

The above split ensures we won't have to deal with any RISC unaligned load nonsense.

It also adds some sanity checks to code that must respect alignment.

We still need fast code for mono_gc_memmove_aligned and mono_gc_bzero_aligned.

We still need to verify if a version of memcpy version is needed. Maybe the extra
branch is not such a perf penalty.
[runtime] Fix the linux build.
[numerics] Fix type in Cosh
[corlib] Fixes formatting of nested tuples
[corlib] Fix implementation of Tuple hash generator

The Tuples.cs code generator dies with:

Unhandled Exception:
System.NotImplementedException: The requested feature is not implemented.
  at TupleGen.computeHash (Int32 destVar, Int32 start, Int32 count) [0x00000] in <filename unknown>:0
  at TupleGen.WriteHash (Int32 destVar, Int32 start, Int32 count) [0x00000] in <filename unknown>:0
  at TupleGen.Main () [0x00000] in <filename unknown>:0

This is caused by the incorrect definition of WriteHash(), which
instead of recursively calling itself is calling computeHash().

Thanks to Marek Safar for reporting the issue in
https://github.com/fsharp/fsharp/issues/188#issuecomment-34351850
[arm] Increase the length of the endfinally instruction. Fixes #17589.
[jit] Avoid running class cctors during AOT when using the AggressiveInlining attribute. Fixes #17558.
Revert "[jit] Align the stack in mono_arch_restore_context () on x86 since it might be unaligned if it was captured asynchronously."

This reverts commit 7798b94706e5552cd1abd80227631f3f9b1bfdad.

Revert this as it breaks debugging on android/x86 (#17410).
[jit] Fix the freeing of AOT jump target lists. Fixes #17201.
Add types from the method header even for gshared methods.
[runtime] Fix the computation of AssemblyName.ProcessorArchitecture () to be compatible with MS.NET. Fixes #17632.
[jit] Hopefully fix the loaded LLVM build.
[runtime] Handle native size of structs with explicit layout and min alignment smaller than default packing. Fixes #4510

The calculating the native size of structs with explicit layout we need to take into consideration the minimum alignment
needed and the packing asked.

If no packing is supplied, we should respect the minimum alignment. If packing is supplied we should use the minimum required.
[runtime] Fix the DISABLE_JIT build.
[metadata] Fix a potential crasher.