Improve performance of DefaultRazorTagHelperContextDiscoveryPhase

[DustinCampbell]

This is some follow-up work after a discussion with @ToddGrun. Previously, @ToddGrun made a change to use pooled lists within the DirectiveVisistors used by DefaultRazorTagHelperContextDiscoveryPhase. However, looking at further traces, there is still a ton of CPU-bound work. Notably, there are loads of string comparisons that happen over and over to compare strings for assembly names. To address this, I've made the following changes:

1. Instead of using pooled lists, the DirectiveVisitors themselves are pooled and they own their data structures.
2. TagHelperDirectiveVisitor has been updated to store a Dictionary<string, List<TagHelperDescriptor>> rather than a flat List<TagHelperDescriptor>. This is used to index tag helpers by assembly name, which greatly reduces the number of string comparisons. The List<TagHelperDescriptor> held stored in the dictionary are pooled to avoid extra allocations of tag helpers per assembly.

[DustinCampbell]

This is still in need of reviews from @dotnet/razor-compiler

[chsienki]

Nit: I don't love the nonComponentTagHelper prefixes in the visitor, as it confused me a bit at first that we were explicitly differentiating but not within the type, but I get where you're coming from.

Seems like another case of 'we need a better name than 'tag helper'' that we were talking about a while back :/

[jjonescz]

we need a better name than 'tag helper'

legacyTagHelper, mvcTagHelper, cshtmlTagHelper...?

[DustinCampbell]

we need a better name than 'tag helper'

legacyTagHelper, mvcTagHelper, cshtmlTagHelper...?

Y'all are free to consider this discussion outside of my pull request. I'm not going to name this here. 😄

[DustinCampbell]

Nit: I don't love the nonComponentTagHelper prefixes in the visitor, as it confused me a bit at first that we were explicitly differentiating but not within the type, but I get where you're coming from.

There are two visitors -- one that applies to "components" and one that applies to "tag helpers". Since both are really built on "tag helpers", it seemed to me that the real distinction is whether a tag helper represents a component or not. If you have better names, I'm definitely happy to use them.