[generator] initial unit test support and refactoring

[jonathanpeppers]

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

[jonathanpeppers]

This is really just the first PR to get this started, tried to do less to make this PR more reasonable to review.

Next steps would be to write unit tests/refactor:

• Methods
• Properties
• Constructors
• Classes
• Interfaces
• Would have to expand SupportTypes.cs as needed

TODO list (for future PRs?):

• Might be good to ignore whitespace in these tests, so the expected strings could look nicer
• Might be good to refactor out comments to their own tests
• Other ideas?