[Xamarin.Android.Build.Tasks] Aot task does not aot "shrunk" linked assemblies - #282

…#282)

Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=32457

The Aot Task was NOT using the stripped assemblies for the AOT process.
This would probably result in code which had been removed being AOT'd.

This bug highlighted a few problems with the current system. Firstly
Java.Interop was NOT part of the SharedRumtime list. As a result it
was being picked up as a UserAssembly not a FrameworkAssembly. This
caused problems during the AoT task when it could not find the
Java.Interop.dll.

Secondly. The AoT Task itself was not making use of the

	@(_ShrunkFrameworkAssemblies)

ItemGroup. This group is updated with the list of framework
assemblies the app is using. Depending on whether the dll's are
shrunk or not this list is the one that contains the final files
that need to be used.

Thirdy there was an issue in the IsFrameworkAssembly Helper method
in MonoAndroidHelper. This issue ment that if an assembly was in one
of the framework directories but NOT in the SharedRuntimeAssemblies list
it would NOT be picked up as a framework assembly. This bug is what
highlighted that fact that Java.Interop was missing in the first place.

Context: https://github.com/grendello/JavaBindingGenerator

@grendello has an initial prototype of a "re-imagined" `generator`. Our
current goal is to refactor the current `generator` and slowly migrate
the existing code to look something like the new one. It obviously is
going to take a while, so we need to do this in a fashion where we can
keep things working while making changes over time. Eventually we may
get to a place where we can import @grendello's existing project to be
used within `generator`.

The high-level changes we should first adopt from the new `generator`:

  - An object model that uses POCOs, such as the
    `Java.Interop.Bindings.Syntax` hierarchy @grendello came up with
  - Logical separation between the `api.xml` parsing and the code
    generation
  - The possibility of "unit" tests, instead of the slow/bulky tests we
    have currently, which are in fact "integration" tests
  - The possibility for new backends that will have breaking changes,
    but allow us to move `generator` forward into the future

This PR is the first step in achieving this, here is a breakdown of
the changes:

  - Moved existing tests to an `Integration-Tests` folder
  - New tests will go in the `Unit-Tests` folder if they are indeed
    unit tests
  - `[assembly: InternalsVisibleTo("generator-Tests")]` will need to
    be added to `generator` so that we can write unit tests against
    `internal` classes and methods
  - Instances of `StreamWriter sw` are changed to `TextWriter writer`
    as needed. This allows us to use a `StringWriter` in unit tests
  - A first set of unit tests are validating the simplest cases such
    as class handles, class invoker handles, and fields
  - A set of "support types" are added to the `generator-Tests` project.
    Once the existing code is reasonably under unit test, these types can
    completely go away as we switch the object model over to POCOs.
  - Any generation methods of `Field` have been moved to the
    `CodeGenerator` base class. This allows us to get `Field` closer
    to a POCO.
  - The constructor of `Parameter` is now `internal` so it can be
    instantiated from unit tests
  - Two sets of new tests are added: `JavaInteropCodeGeneratorTests`
    and `XamarinAndroidCodeGeneratorTests`, unit tests within take
    around 1ms, so we can add as many of these as we like
  - Usage of `CodeGenerator.ContextType` are being refactored during
    the migration, as it seems to be a code smell. While writing each
    unit test, I could easily discover the `ContextTypes` stack usage
    because exceptions are thrown. Hopefully, we can remove
    `ContextType` completely as refactoring continues, and just pass
    the required value through an additional parameter.

NOTE: in this PR, I've (hopefully) not altered the output of
`generator`. I have noticed a few bugs/oddities in the output, but plan
to fix these in future PRs after we have these tests.

Miscellaneous changes:

  - VS for Windows unit test runner wants to add a `<Service />` MSBuild
    item, I'm not sure what this is for, but it is a hassle to keep
    discarding it
  - Updated `.gitignore` for VS for Windows