[Fixes #393] Update ViewComponent result apis to be consistent with Controller

1. Updated ViewComponent to expose similar properties to the existing ones in Controller where
appropiate. We've left out Resolver for being a bad pattern (just inject the dependency on the constructor
or use Context.RequestServices to access it if needed) and Response as although available through the Context property, it shouldn't be used/modified in a ViewComponent.

2. Updated ViewViewComponentResult to follow a similar pattern as ViewResult where the constructor is
parameterless and elements like ViewEngine are resolved during execution if the user does not set the
associated property on the object.

3. Updated ExecuteAsync in JsonViewComponentResult to remove the unnecessary pragma and async keyword from the signature and to use Task.FromResult(true) instead.

4. Cleaned up ViewViewComponentResult tests.
agree user can change `ViewData` in their `ViewComponent` and (unfortunately perhaps) that won't write through to `ViewContext.ViewData`.  my specific concern is what happens to properties from `ViewData` after that update.
- `ViewBag` won't change if it's already been initialized but will point to the new `ViewDataDictionary` otherwise
- `ModelStateDictionary` will always reference the dictionary in the `ViewContext`
- `View()` will always render using the updated `ViewDataDictionary` instance

basically, should the following change the model state in `ViewContext` or just the "local" `ViewData`
``` c#
  ViewData = new ViewDataDictionary<NewModel>(ViewData);
  ModelState.Errors.Clear();
```

Note the `Component` equivalent of this property returns `ViewData?.ModelState`.  Of course component doesn't have a container property holding a `ViewDataDictionary` instance.  But I think we should be consistent here.