Fix for MVC #1539 - Deal with the case where request services are not set

Rather than throwing here, this does what routing does. If request
services aren't set, we just create our own scope.

This will NOT create an extra scope if request services are already set.
Revert "Fix for MVC #1539 - Deal with the case where request services are not set"

This reverts commit d9a3c265eaa13012c5f4d0f68bfe6d8b8fe6e948.

This was the wrong commit, did not intent to merge this.
Adding a functional test that modifies data tokens

Tracked by aspnet/Routing#116

The product support for this feature is in already this change just adds a
test verifying the scenario.
Fix for #1447 - Adding functional tests that verify per-request services

These tests verify that per-request services can be injected into assets
that users provide/implements (filters, constraints, controllers, views,
etc).

The purpose is to verify that the services are correctly resolved from the
per-request service container, and don't have state that lingers and
influences the next request. This is important because changing the
lifetime of a framework services could easily impact the lifetimes of
others, and ultimately of something the user created.
update due to breaking changes in routing
ReadOnly attributes for Action, Controller, and Parameter
Update per comment
Reacting to DataProtectionServices being removed from hosting services
Merge branch 'actionmodel1495c' into dev
changed contract.assert to debug.assert
Fix for #1194 - Error using [HttpPost] and [Route] together

This change enables some compatibility scenarios with MVC 5 by expanding
the set of legal ways to configure attribute routing. Most promiently, the
following example is now legal:

[HttpPost]
[Route("Products")]
public void MyAction() { }

This will define a single action that accepts POST on route "Products".

See the comments in #1194 for a more detailed description of what changed
with more examples.
Checkin VS modifications to kproj

My up-to-date VS wants these projects to have port numbers. Makes sense
because they are web projects.
MVC tag helpers should not override tag name in Razor source
- #1523
- remove `TagHelperOutput.Merge()` extension method entirely
- test tag name preservation with all MVC tag helpers
 - `<input/>` tag helper generation of a checkbox wasn't previously tested

nits:
- fix argument order in a couple of `Assert.Equal()` calls
- remove use of "original tag name"
Address small `InputTagHelper` bug discovered while testing
- Type attribute value was "Type", not "type", when determined from template hints

nit: remove useless condition
Add more tests of `<input/>` tag helper
- scenarios where helper takes different code paths were not well-explored

nits:
- improve a few comments and names
- refactor some setup code into helper methods
- use `EmptyModelMetadataProvider`, not `DataAnnotationsModelMetadataProvider`

Test gap around `GenerateTextBox()`'s `format` argument is temporary.
React to aspnet/Razor#214 changes.

- TagHelperAttributeDescriptors changed to be lighterweight and not depend on PropertyInfo, had to modify our use of them to work with the new contract.
React to aspnet/Razor#214 mvchook changes.
Fix for #1539 - We're not going to do anything special when request
services aren't enabled

This is just removing the TODO.
React to aspnet/Razor#210 changes.
Adding unit tests for HtmlHelper.Password

Partial fix for #453