[generator] (class-parse regression) mark obfuscated types in generator.

[atsushieno]

DO NOT MERGE THIS WITHOUT MERGING dotnet/android#249 first (yes, that PR can be merged without this)

Basically this is part of the problems reported at
https://bugzilla.xamarin.com/show_bug.cgi?id=44263

In good old jar2xml era, we marked "obfuscated" types at jar2xml so
that those types are not generated in the API XML.

class-parse is not that clever and generates everything as is.

We could make changes to api-xml-adjuster to bring back sanity, but
instead of doing it in jar2xml, we had better bring in flexibility
to obfuscation marking. That is -

• If there is obfuscated='false' attribute specification by API
  metadata fixup, then do not mark as obfuscated in any case.
• If not, process any lowercase-named types and nested types as
  obfuscated, such as 'a', 'SomeType$a', or 'SomeType$b$a'.

Due to code structures, we cannot take the same code path as jar2xml
(we don't hold list of sibling classes when processing an XML element).
https://github.com/xamarin/jar2xml/blob/master/JavaPackage.java#L78

Also, we had seen some obfuscated types like b$a as NOT marked as
obfuscated in the past, because we were checking only a,aa,aaa,aaaa and
aaaaa as the parent type for nested types. That should be fixed.

To fix this issue, we process marking as part of StripNonBindables().
Also, it was too early to register those types to SymbolTable before
stripping those types out, so changed relevant processing order.

Fixing bug #44263 then exposed another problem; StripNonBindables()
was not complete and it was not processing nested C# types at all.
Thus we had generated non-bindable code before. This change fixes this
issue at the same time, for fixing the bug.

Thus, this will result in "API breakage" looking changes in the end,
but the bindings were invalid and should be removed without
compatibility concern.

[atsushieno]

https://bugzilla.xamarin.com/show_bug.cgi?id=44530 can be also fixed.