[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
Merge pull request #895 from ranma42/fix-tuple-hash-codegen

[corlib] Fix implementation of Tuple hash generator
Merge pull request #892 from initram/master

Implemented Parse() and TryParse() for System.Numerics.BigInteger and DaysInYearBeforeMinSupportedYear for Calendars
Revert "Merge pull request #829 from symform/httpwebreq-async-ssl"

This reverts commit 35899c07fff7f7e4c6533364091bbac6ce86fdfd, reversing
changes made to 80166fd02fadc470e40b59df0c8c65c19945ed21.
[corlib] Mark awaited task exception observed when GetResult does the wait
[sgen] Fix overflow occurring with large object allocations.  Fixes #17590.
[sgen] Hint OOM exception branch as not taken.
[sgen] new T[-1] must throw OverflowException, not OOM.

Fixes failure in mini/arrays.cs.
[runtime] Remove overly pessimistic test.

The test asserts that we can't allocate int arrays with 2G elements.
With SGen on 64 bits, however, we can, which is a feature, not
a bug.
[system.xml] Support more primitive types in XmlReader::ReadContentAs
[arm] Use d0/d1 as fp scratch regs on non-hard float platforms. Hopefully fixes #17597.
[system.xml] Add more invalid argument checks
[system] Updates to WebUtility decoders and encoders
[NTLM]: Add new 'NtmlSettings' class to hold the 'DefaultAuthLevel' property.

When the NTLM sources are compiled into System.dll, then we need to store the
configuration variables there and peek/poke it in Mono.Security.
[mcs] Don't report any not applicable operator errors during constant folding.
[xbuild] Fix mscorlib resolution for custom frameworks

Now that mcs supports multi-targeting, we can use the MSBuild 4.0+
system of finding mscorlib.dll in the target framework folders and
passing it to the compiler, along with the /nostdlib argument.

Like MSBuild, the old NoStdLib property can be set to true to disable
passing mscorlib.dll to the compiler, and the new NoCompilerStandardLib
property can be set to false to disable passing /nostdlib to the compiler.

This makes custom target frameworks work correctly without having to
override CscExe with a wrapper script.
[xbuild] Fix typo that broke 2.0/3.5 targets
[xbuild] Make ToolLocationHelper work better for 2.0/3.5

Mono keeps unversioned tools in the 4.5 directory, so look there
for 2.0. Additionally, most 3.5 tools are in the 2.0 directory.
[xbuild] Fix Tooltask.ToolPath behaviour to match .NET
WebRequest: Provide stub ImpersonationLevel

The old implementation threw an exception requesting that the method be implemented
in a derived class, but the method is not virtual, so it could have never been
implemented.

Since Mono does not support this, at least we keep the token around and avoid
throwing.