…ster.

Until now, ApiXmlAdjuster was trying to resolve types using
ClassGen.BaseGen property which is in fact assigned only after Validate()
step in generator. API XML analyzer work is done way before that step,
and therefore it failed to resolve types from managed code (DLL references).

Missing type hierarchy in Java type model from managed code means that
any bindings that references Mono.Android (which wouldn't?) had to rely
on insufficient hierarchy. Especially, it failed to resolve method
overrides when the target Java library types overrode methods in android.jar
indirectly.

SherlockExpandableListActivity.addContentView() was such a method.

And it had appeared as a regression from our MSBuild tests[*1].

Fixes:

- removed dependency on BaseGen in ApiXmlAdjuster. Use BaseType instead,
  which doesn't depend on validation step.
  - Though this change uncovered an issue that Ctor and Parameter needed
    to hold Java type information. So, made some changes to them.
- Now that ApiXmlAdjuster is getting valid managed type hierarchy, it
  had uncovered another kind of issues: managed objects need to exist
  to not cause some null crashes. Hence there is ManagedType class now.
  - Type resolution now premises this ManagedType in type resolver code.
- Fixed incorrect Load() invocation for ClassGen and InterfaceGen (that
  had caused missing BaseType information).
- Added (almost irrelevant) ApiXmlAdjuster test to make sure override
  resolution is done for overrides from indirect inheritance.

[*1] that needs to be OSS-ed...