Fix the date time set in file by removing the ':'.

This is the same code than the one under SendCore. The date time should
not have the : (time zone offset) to be able to use the file.
[Mono.Parallel] Removed broken Mono.Threading.Tasks code

The code in MonoTaskExtensions.cs relied on the internal method Execute(Action<Task>) in System.Threading.Tasks.Task which was removed in 0a66e60.
Added stress test to ConcurrentQueue.TryPeek.
The test checks that in some race condition the queue does not return null.
Changed TryPeek to handle race condition with Dequeue.
Dequeue sets the head.Value to its default. When TryPeek is interrupted in the process of retrieving the value some times Dequeue sets the value to its default. TryPeek now checks the head has not been changed before returning the value.
[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
[mcs] Inflate nested pointer containers too.
[mcs] Resolve event expression when testing left side expression. Fixes #20493
[mcs] Check for missing dependencies of container types. Fixes #20382
[Http]: Fix a potential race condition in the WebConnectionGroup's connection list.

Remove the "ConnectionState" from the connection list before closing the connection,
this should avoid ServicePoint.SendRequest() ever crashing with a NullReferenceException
due to getting a null return value from WebConnectionGroup.GetConnection().
[jit] Don't emit a write barrier when writing to the delegate->method field, its not needed.
[Mono.Debugger.Soft] Handle cases where the instruction list is empty
[mcs] Add support for await in finally clause