Redesign TagHelper content modes.

**Removed ContentBehavior**
- Removed all tests and instances of ContentBehavior in preparation for moving to a non-ContentBehavior based design.
- Removed ContentBehavior specific CodeGeneration.

**Re-design TagHelperOutput and runtime dependencies to allow all content modes.**
- Added PreContent, PostContent and ContentSet properties to TagHelperOutput.
- Added GeneratePreContent, GeneratePostContent and SupressOutput methods to TagHelperOutput.
- Added multile ExecuteChildContentAsync and GetChildContentAsync to the rendering phase, ultimately only exposing GetChildContentAsync to a TagHelper author.
- Added more knowledge of StartWritingScope and EndWritingScope to the TagHelper runtime components. This is to enable the runtime components to utilize the RazorPage's infrastructure to render a delegate to a writer and retrieve its value to ultimately expose it to the user.

**Modify tests to allow new content mode design for runtime components.**
- Added a new internal ctor for TagHelperExecutionContext since it's used in multiple tests to allow for less friction testing.

**Added CodeGen for TagHelper content mode redesign.**
- Modified the CSharpTagHelperCodeRenderer to understand a single line of TagHelper rendering (instead of doing different things based on ContentBehavior).
- Modified existing CodeGen output to reflect new content changes.

#221

***Note:*** Will add tests once design is good.

/cc @dougbu @pranavkm 
It was a tough call, the caching logic is done indirectly in the `TagHelperExecutionContext`. The reason why it's done there is because the CodeGen needs access to it and CodeGen doesn't have access to the `TagHelperContext` since `TagHelperContext` is 1-1 with each `TagHelper` and created inside the `TagHelperRunner`.

It's a rough situation but I'm open to alternatives.