Game class support for WinRT XAML (NEEDS TESTING!)

This pull request adds support for another way of creating a Windows 8 MonoGame app.  This menthod allows you to use XAML UIs, but not lose the ability to use Game and GameComponents.

There are currently 3 methods in MonoGame for creating an Windows 8 application.

### GameFrameworkViewSource

This method was the first one developed.  It works like this...

```
static void Main()
{
   var factory = new MonoGame.Framework.GameFrameworkViewSource<MyGameClass>();
   Windows.ApplicationModel.Core.CoreApplication.Run(factory);
}
```
... this works very similar to how initialization is done on XNA for Windows or Xbox.  The main trouble with this technique is it creates its own application framework which cannot host XAML content.


### The Silverlight Method

This next method was created to get XAML support via mimicking how XNA+Silverlight apps work on WP7.  It is a more low level technique which has the user create a SharedGraphicsDeviceManager and GameTimer objects...

```
_manager = SharedGraphicsDeviceManager();
_manager.PreferredBackBufferWidth = (int)((XamlSwapChainPanel.Width * (dpi / 96.0)) + 0.5);
_manager.PreferredBackBufferHeight = (int)((XamlSwapChainPanel.Height * (dpi / 96.0)) + 0.5);
_manager.SwapChainPanel = XamlSwapChainPanel;

_timer = new GameTimer();
_timer.UpdateInterval = TimeSpan.Zero;
_timer.Update += (o, a) => Update(new GameTime(a.TotalTime, a.ElapsedTime));
_timer.Draw += (o, a) => Draw(new GameTime(a.TotalTime, a.ElapsedTime));
_timer.Start();
```

While this method is what some WP7 developers have used it suffers from one major flaw... you lose use of the Game and GameComponent classes.  At first this doesn't seem like a big loss... but soon you realize it is a huge one.  You will find all sorts of 3rd-party XNA libraries that depend on GameComponent or Game.  Worse you loose all the abstractions Game provided to Window events and game state which becomes a huge problem when targeting multiple platforms.


### XamlGame

This new method in this pull request offers the best of both techniques.  You get the Game classes as well as use of XAML.  The usage is very simple...

```
_game = XamlGame<MyGameClass>.Create(launchArguments, coreWindow, swapChainBackgroundPanel);
```

... this code typically goes into your App.xaml.cs or your main GamePanel classes.

You can freely call into your Game class from XAML code or have your Game class call XAML code itself.  You can use all the normal Game class features and events like Game.Window.ClientSizeChanged, Game.Content, Game.IsMouseVisible, etc.

I stopped short of supporting more exoteric scenarios like multiple Game classes in one XAML app or changing the SwapChainBackgroundPanel during gameplay.  If we find users have a need for more flexibility we can add it in MonoGame 3.1.


### Keeping The 3-Way

While we should strive to keep down complexity i think for now i recommend keeping all 3 techniques.  Not only would be disruptive to people shipping games for Win8 launch to remove any of them, but really depending on your goals you might want one over another.  

Later we should evaluate the usage of the different methods and either find ways to merge functionality or remove one or more of them.


### To-dos

There are a few things we need to do related to these changes:

  - We need a document explaining the three methods and their trade offs (this pull message is a good start).
  - We need to implement VS2012 templates for all 3 methods.
  - Need to port some samples to use these techniques.

... these are most likely tasks that will fall into other pull requests.