Fix issues with DefaultHttpControllerTypeResolver

Make the implementation more robust in handling exceptions from getting exported types: The existing implementation did not handle exceptions thrown by Assembly.GetExportedTypes which caused problems when loading assemblies that had external dependencies which were not also loaded.

Also added substantial new unit tests to cover DefaultHttpControllerTypeResolver.
Enabling re-running routing in ASP.NET Hosted environment.

Normally, routing is already run in ASP.NET when requests are dispatched to ASP.NET Web API. However, there are situations where routing may have to be re-run:

1) Batching: The inner requests (embedded in a single outer request) don't have routing associated with them and so we have to be able to run routing again.

2) URI-rewriting: In case of URI-rewriting in a message handler, the existing route data no longer applies.

For self-host, this is not a problem as we run routing in the HttpRoutingHandler but we didn't compute a new route in hosted and hence these requests failed. We now provide enough information for routing to run in hosted as well.
Reversed the order in which HttpMessageHandlers are wired up.
HttpMessageHandlers used to be invoked in a bottom-up manner where the last entry is called first for a request message but last for a response message.
However, this is inconsistent with the way filters are wired up and so to provide a more uniform experience we have re-ordered the way in which HttpMessageHandlers are wired up to match that of filters. HttpMessageHandlers are now invoked in a top-down fashion. That is, the first entry is invoked first for a request message but last for a response message.
Upgrade DNOA packages to latest version.
Clean up ProviderUserIdSerializationHelper class to incorporate review feedback. Add clarification comments.
Removed unused internal code and fixed up related test to use [Theory] instead of hard-coded values.
Optional parameter fixes
There're currently two issues with our optional parameter support
1. The default value on the optional parameter is not applied when using FormatterParameterBinding
2. We don't recognize an optional parameter when the default value is null (tracked by http://aspnetwebstack.codeplex.com/workitem/148)

For #1, we've decided not to support it by throwing. It's relatively uncommon to have optional parameter for the body and the formatters should be the ones deciding what to return for the default values.
For #2, we're introducing IsOptional concept to HttpParameterDescriptor so we're not relying on the default value because it can be null for optional parameters.
Adding unobtrusive JavaScript files to System.Web.Mvc
Fix up package references from OAuth update
Fix unit tets failing.
Updated default content negotiation to take into account whether accept headers are matched by one of three possible accept header values

1) A literal media type, e.g. "application/json",
2) A subtype media range, e.g. "application/*", or
3) An all media range, e.g. "*/*.

Within the same band of q-factor values, e.g. "1.0", the preferred response media type is picked in the order 1), 2), 3). That is, an accept header value of "application/xml" is preferred to the less specific "application/*" which again is preferred to the less specific "*/*.

Examples of matches:

Accept: */*, application/xml
Response: application/xml

Accept: */*; q=1.0, application/*; q=1.0, text/xml; q=1.0
Response: text/xml

Accept: */*, text/*, text/xml; q=0.5
Response: text/json

Also fixed a bug in the quality comparer logic which didn't account appropriately for a q-factor of null (which is equivalent to 1.0).
Throw an exception for validation attributes on non-public properties and fields and for [Required] without [DataMember(IsRequired=true)] on value-typed properties
These fixes cover situations where users might think their validation is running, but it in fact isn't. Validation attributes only run for public properties. So any validation attributes on non-public properties and fields need to cause an exception to be thrown. Certain formatters (like XmlMediaTypeFormatter) don't recognize [Required]. So we need to throw an exception if [Required] is present without [DataMember(IsRequired=true)] to make sure that the formatters recognize the required member.
For clients, the experience in these cases is that they will get an HTTP InternalServerError. If the client is local, the exception message will appear which should allow the service author to diagnose the issue. The service author can choose to ignore these errors by removing the InvalidModelValidatorProvider from their configuration services for ModelValidatorProvider.
Issue 61 -- enable bufferless input stream in web-host

Fixes issue http://aspnetwebstack.codeplex.com/workitem/61

This change adds support for the developer to control whether request
input streams are buffered or unbuffered in a web-hosted environment.

This is done by registering an IHostBufferPolicySelector implementation
in the configuration (typically done in Global.asax.cs), such as:
   GlobalConfiguration.Configuration.Replace(typeof(IHostBufferPolicySelector), new MySelector());

If this implementation returns true from UseBufferedInputStream(Request), the input
stream will be buffered.  If the implementation returns false, it will be unbuffered.

By default, request input streams are always buffered.
Zero ContentLength without content type header in body is throwing
The selection of formatters will depend on content-type header. That means when there's no content-type, no formatter will be selected, and the parameter pick up the default value.
Cleanup from the earlier Anti-XSRF DCR:

- Refactored types so that the dependency chain is initialized in a single place rather than having each component create a default instance of its dependencies.

- Use the 4.5 MachineKey APIs if the application is targeting 4.5.
Removed non webapi projects