Consider moving TagHelperOutput.Generate*() functionality to RazorPage.Write in Mvc.

[sornaks]

Quoting @dougbu 's comment:

for future consideration (not this PR) but related to the TagHelperContent / DefaultTagHelperContent split introduced here: suggest we split TagHelperOutput along similar lines and get the Generate*() methods and perhaps ContentSet out of tag helper authors' faces.

This split could go further and move the Generate*() methods completely out of this class (or class hierarchy). if _isTagNameNullOrWhitespace were exposed as a property (like ContentSet), these methods would not require any private information. could move generation many places but I suggest the RazorPage.WriteLiteral[To]([TextWriter,] TagHelperExecutionContext) methods I proposed elsewhere. in any case, this would pull apart the mix of responsibilities TagHelperOutput has today.

[dougbu]

the general point is to revisit what we expose in TagHelperContent and how we use that class in the framework. this includes looking closely at the boilerplate code generated for tag helper scenarios.

another comment from the same review:

not necessarily a part of this PR: suggest we create WriteLiteral(TagHelperExecutionContext) and WriteLiteralTo(TextWriter, TagHelperExecutionContext) overloads in RazorPage. no reason to generate the boilerplate code from WriteLiteral(__tagHelperExecutionContext.Output.GenerateStartTag()); through this line. possible to include the RunAsync() call in the methods but that doesn't fit well into a "WriteSomething()` method.

[danroth27]

@sornaks Please work with @DamianEdwards @NTaylorMullen @dougbu on this.

[sornaks]

7daec14 and aspnet/Mvc@c1338a0