…want you to review then decide whether it's acceptable.

As you know I was in a project which utilized RESTier as a hub to integrate all its feature logic. And since we played with dynamic types generated at runtime, it was very hard (if not impossible) to work at WebApi level. So it made me believe that a powerful DI framework in RESTier will have its unique value.
Of course you guys will make the decision, and I'll respect either way.

This is to incorporate Micorsoft DI framework into RESTier, to replace current Dictionary<,> based service registration.
Pros:
* Powerful - lifetime control, various ways to register a service, service composition etc. All the features that DI framework supports.
* Backward compatible at API level. Existing hook handlers keep working as expected.
* Enable injecting any type of services, i.e. other than IHookHandler.
* Scope capable, although not implemented yet in this change, but it would be quite simple.
Cons:
* Dependency on DI libraries. Although it's possible to use any other DI container, we have to add default DI implementation as reference.
* Minor perf hit on service registration, which IMO has no real impact.
* Can't resolve hook handlers before EnsureCommitted().