[mcs] Handle catch filter with await-ed rethrow and exception filters
Merge pull request #1097 from BrzVlad/master

[jit] Fix bug when using pushless code and reenable the feature.
Disable push-less x86 code for now.

Breaks stuff: https://wrench.mono-project.com/Wrench/ViewLane.aspx?lane_id=10&host_id=8&revision_id=68534
[x86] Reduce some code duplication in the x86 call opcodes.
since gerror.c requires vasprintf.h, we need to add that file so that it becomes part of the tarball
Merge pull request #1098 from tpokorra/TarMissing_vasprintfh

tarball is missing file vasprintf.h
[x86] Pop the vtype return addr from the stack in no pushes mode too.
[mcs] Keep stack populated when array initializer contains await
[mcs] Emit correct value type collection initialization when second initializer uses await
[corlib] Set AggregateException message text in all overloads
[mcs] Always store hidden catch variable when clause contains await
[runtime] Rewrite MemoryMappedFile to support named mappings.
[runtime] Fix share/private flags when doing file mmap.
[System.Core] Add new tests for MemoryMappedFile.
Monodoc: Fix for CDATA bug (https://bugzilla.xamarin.com/show_bug.cgi?id=17850). Reverts 3f361e1a263fc23680beab62eadde0cd3e4ac64d

Removed code that stripped CDATA statements (but not blocks) from input when showing a namespace page:

The function Ecma2Html.WrapStream(TextReader,Dictionary<String,String>) very explicitly returns a new `AvoidCDataTextReader` when the system is showing a namespace. The `AvoidCDataTextReader` strips the CDATA statement, but not it's internal contents. The intent, according to AvoidCDataTextReaderTests, is to allow class summaries of this form:

"<elements><summary>Addressbook APIs.</summary><remarks /><class name=""ABAddressBook"" fullname=""MonoTouch.AddressBook.ABAddressBook"" assembly=""monotouch""><summary><![CDATA[
      Provides access to the system Address Book.]]>
    </summary></class></elements>"

But that form is not desired.

The bug arose because the input to `WrapStream` is very large (it actually includes the entire *description* for each class and member in the namespace!). If any CDATA-block contained entities such as, e.g., < or >, the resulting XML would (obviously) be ill-formed:

"<xml>This should be valid <![CDATA[<T>]]> </xml>"

would throw because the <T> would be attempted to be parsed as XML. Obviously, samples that contain generics or lambda or XAML would cause this problem.

Although an XMLException was thrown, Macdoc swallows the exception in DocTools.GetHTML(). That is why this caused a silent failure on macdoc and was visible on Webdoc.
[x86] Fix initialization of stackalloc-ed memory in no pushes mode.