[Design] Fix for #975 - Implementing IActionConstraint and ActionMethodSelectorAt...

...tribute

IActionConstraint follows a provider model similar to filters. The
attributes that go on actions/controllers can be simple metadata markers,
the 'real' constraint is provided by a set of configurable providers. In
general the simplest thing to do is to be both an
IActionConstraintMetadata and IActionConstraint, and then the default
provider will take care of you.

IActionConstraint now has stages based on the Order property. Each group
of constraints with the same Order will run together on the set of
actions. This process is repeated for each value of Order until we run out
of actions or run out of constraints.

The IActionConstraint interface is beefier than the equivalent in legacy
MVC. This is to support cooperative coding between sets of constraints
that know about each other. See the changes in the sample, which implement
webapi-style overloading.
That's exactly the use case for the provider, and this is consistent with the design for filters. Not inclined to change that if the providers are a feature.

>The alternative would be to write a provider and do it there, but I think that writing a provider is much more complex than writing a factory and something that is more aligned with providing a constraint programatically in scenarios where you need context on the other actions defined in the application.

The factory gives you the ability to type-activate or service resolve the constraint, that's the primary reason why you'd use it over the constraint directly.

If you're implementing some sort of application-wide policy (like versioning) then it's best done as a provider where you get more context. It's actually pretty straightforward to do.