Monodoc: Fix for CDATA bug (https://bugzilla.xamarin.com/show_bug.cgi?id=17850)....

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.