Add Web API support for both WebHost and SelfHost scenarios

This is a massive change, or at least it is in terms of organization. Core code really hasn't changed. There are specs for Web API with the feature files finished, but tests are missing for all the other standard unit tests (Translations, notably).

You don't need to pull this in right now, rather I want to keep this open to track changes and discuss them. I've tried to keep the structure mostly the same as it was before, and hopefully most of the changes make sense.

## Major Changes

### Generics

The biggest change has been the switch to generics for most of the core framework classes; bubbling up to the entry point: configuration. In order to keep the generic ugliness out of client code, I've implemented derived classes for each of the 3 frameworks: Mvc, WebHost, and SelfHost. These contain hardly any logic, they are there for a clean veneer over the underlying API.

I am working to reduce the need for generics, so we'll see how far I can get. I had an idea of using a Pipeline architecture perhaps, where it may be possible to define 3 pipelines for handling core logic, and letting the 3 frameworks implement the correct attributes (because they **must** implement the correct interfaces for the frameworks: `IRouteConstraint` in MVC, `IHttpRouteConstraint` for Web API). WebHost is significantly easier to integrate with the core of AR, because it only requires two different types: `IHttpController` and `RouteParameter`.

### Namespacing

It looks like there's a ton of projects, and there are, but it's mostly to keep with the ASP.NET web stack convention and to implement derived classes that simply implement the proper framework interfaces.

### Attributes

Unfortunately, there's no getting around being forced to create derived attributes for each framework because Web API and MVC have different interfaces they look for. I tried to keep the base logic in both `AttributeRouting` and `AttributeRouting.Web`.

### Projects

Quick rundown, but each should be self-explanatory:

* **AttributeRouting** - Core library, **no** web dependencies whatsoever
* **AttributeRouting.Web** - Core web library, dependencies on System.Web and System.Web.Routing. This is the base for MVC and ASP.NET Web API (not self-host).
* **AttributeRouting.Web.Http** - Core HTTP library for self-hosted and web-hosted Web API projects
* **AttributeRouting.Web.Http.SelfHost** - Self-host specific derived classes for Web API
* **AttributeRouting.Web.Http.WebHost** - Web-host specific derived classes for ASP.NET Web API
* **AttributeRouting.Web.Mvc** - ASP.NET MVC specific derived classes

The main reason I decoupled everything was for ease of downstream consumption. If I'm doing a MVC project, I don't want Web API DLLs in my project. If I'm doing only ASP.NET Web API, I don't want MVC stuff in my project. If I'm writing a Web API console app, I don't need web stuff. This just keeps everything nice and separated, no un-needed dependencies.

### Http Convention

For most of the Web API-specific stuff, I prefix everything with `Http` to keep in line with what MS is doing. So it is `HttpAttributeRoutingConfiguration` and `MapHttpAttributeRoutes`. This makes it easier to use MVC and Web API at the same time, which will probably be the most common.

Some things are not prefixed with `Http`. All the standard HTTP methods aren't: GET, POST, PUT, DELETE, OPTIONS, TRACE. I am not sure if this is OK, it feels weird to make them prefixed and hopefully people will not accidentally use MVC namespaces in their ApiControllers.