Identities not being set in ClaimsPrincipal Ctor

Class' identities member is not set in constructor ClaimsPrincipal
(IEnumerable<ClaimsIdentity> identities)
Merge pull request #1094 from LRFalk01/master

Identities not being set in ClaimsPrincipal Ctor
Add build system plumbing for building with -Werror.
Attempt to sanitize the `vasprintf` situation in eglib.

The problem is that on some platforms we call the function
without having provided a prototype for it. This breaks when
building with `-Werror`.

Now we declare it in the private `vasprintf.h` header when
the platform doesn't have a declaration in `stdio.h`. This
should also let us remove the hack in `glib.h` for MSVC.

This may or may not break the build on some platforms; I've
tried on those that I have access to with success. Let me
know if this breaks anything.
[sys.xaml] fix TypeId and get broken WindowsBase tests pass.
Changed mono_win_chained_exception_needs_run to be a JIT TLS variable.

This fixes a potential race condition that might happen if two threads try to handle an exception at the same time.
Fix mono exception handler crashing on windows.

Here's the scenario that causes the crash:

Exception is fired, which invokes mono's vectored exception handler. It
is not an exception mono recognizes, so falls through to the default:
case in the exception handler. The problem is the return value has been
initialized to EXCEPTION_CONTINUE_EXECUTION. This causes SEH not to
process any other handlers, and just attempt to continue execution at
the point the exception was thrown.

The problem is much of windows internals will catch various exceptions
internally and handle them. So instead of the exception being handled,
we would just crash in the bowels of windows.

The solution is to set mono_win_chained_exception_needs_run to TRUE in
the default case - this is what the various exception handlers do if the
exception is not in JIT'd code. This causes the handler to return
EXCEPTION_CONTINUE_SEARCH, which causes SEH to search for the next
handler, and no crash is produced.

Both x86 and x64 had this bug, so I fixed it in both places.

Fix contributed by Steve Anichini.
[Mono.Debugger.Soft] minor code cleanup
[Http]: Only recycle ServicePoints from the idle timer (fixes #19823).

Thanks a lot for Martin Potter to find and report the race condition
which was causing the problem.

ServicePointManager.RecycleServicePoints() was a left-over from the
old times when we didn't have an idle-timer based approach.
[windows] Return early in the vectored exception handler if the thread is not managed by the runtime.
[Mono.Debugger.Soft] Improved ILInterpreter to eval properties that return a primitive constant
[System.Net.Http]: Always add "Content-Length" in HttpClientHandler.SendAsync().

This has been reported on the forums:
http://forums.xamarin.com/discussion/17770/length-required-error-in-http-post-since-latest-release
[Http]: Fix digest authentication (bug #18799).

We did not correctly parse key-value pairs without quotes in the
challenge.
[mcs] Implement rethrow support in awaited catch clause
[Http]: Cosmetic, remove some dead code.

The is no reason to ever invoke the callback on the ThreadPool,
it would in fact only cause trouble.

Marek's commit db92449f was correct, I removed the commented out
code and the no longer used method.
[sgen] Fix an infinite loop in find_previous_pointer_fragment due to remove CAS'ing the wrong value.

The fragment list has one invariant, the next pointer is tagged if the current fragment is been deleted,
which means the list head can never point to a tagged pointer.

If this invariant is broken, the code in find_previous_pointer_fragment will end up in an infinite loop.

The infinite loop happens in this simplified fragment:

try_again:
	prev = &allocator->alloc_head;
1)	cur = unmask (*prev);
	while (1) {
2)		if (*prev != cur)
			goto try_again;

So assume allocator->alloc_head points to 0x121, which is tagged.

So execution goes like this:

1) cur is set to 0x120
2) *prev (value 0x121) is different than cur (value 0x120) so retry.

The above will loop forever as the fixup code never touches allocator->alloc_head.

Now that we understand the infinite loop, let's see how the remove code can trigger it.

Use use the following notation in the event sequence:

-> a non tagged pointer
-*> a tagged pointer
first CAS: InterlockedCompareExchangePointer ((volatile gpointer*)&frag->next, mask (next, 1), next)
second CAS: InterlockedCompareExchangePointer ((volatile gpointer*)prev_ptr, next, frag)

Assuming the following initial fragment list and two threads removing two separate fragments:

fragment list; -> A -> B -> C

thread 1 removes A
thread 2 removes B

thread 2 succeed the first CAS
-> A -> B -*> C

thread 1 succeed the first CAS
-> A -*> B -*> C

thread 2 fail the second CAS because of thread 1
-> A -*> B -*> C

thread 1 succeed the second CAS
-> B -*> C

thread 2 succeed the second CAS and set prev_ptr to next,
which at this point is a tagged pointer. Leaving the fragment list like this:
-*> C

After the last CAS, we end up with alloc_head with a tagged pointer, which will cause
the infinite loop we previously explained.

The fix is to unmask the value we store in the second CAS, as the objective is to link
two live fragments and not flag the previous fragment for deletion.

The exact same bug exists in mono-linked-list-set and was fixed there.
[Mono.Linker] Add support for <Module> with static method and pre-mark them if necessary
[Mono.Linker] Add support for using the linker with assemblies referencing WPF
Merge pull request #890 from xoofx/master

[Mono.Linker] Add support for <Module> with static method and pre-mark t...
[mcs] Flow analysis of binary expressions not using logical operators. Fixes #20515