[Design] Add TagHelperDescriptorResolver implementation.

- Added a basic TagHelperDescriptor creation mechanism to the TagHelperDescriptorResolver.
- Added an ITagHelperTypeResolver to be responsible for determining valid TagHelper types.

#99
have you forgotten `TagHelperDescriptorResolver` performs `string` -> `TagHelperDescriptor` mapping?  that's it's responsibility -- look at the signature of the `Resolve()` method.

this processing includes at least the following stages:
1. parse the `string` to determine the correct assembly and perhaps type (this is overly complex at the moment because you're not using `AssemblyName.TryParse()` or similar methods that already have a defined syntax)
2. do reflection to load the assembly and get an `Assembly`
3. filter `Type`s declared in the `Assembly` based on point 1 and a short set of rules
4. map `Type`s to `TagHelperDescriptor`s

you've split things between point 3 and 4 and are _sure_ that's the right split?  why not e.g. split things vertically -- place lower-level details in (perhaps `static`) helper classes?  or some other split based on the eventual size and number of similar methods?

in addition, the current split hides top-level information in `TagHelperTypeResolver`.  again the top-level class is this one.

finally don't worry about making this class large.  even with the validation (that hasn't been triaged) and `TagHelperTypeResolver`, this class will be small as Razor classes go.

----
on the interface, you've made a good point.  why should core Razor need to load the runtime assembly?  this class should be in core Razor since it's not used after chunk generation, unlike e.g. `TagHelperRunner`