Clean up TagHelperFactsService and friends

[DustinCampbell]

This change cleans up the tooling layer's TagHelperFactsService to consume and return ImmutableArray<T> rather than IReadOnlyList<T>. I've gone through all code using this service to ensure that any boxing is removed or eliminated. I also eliminated several other allocations (e.g. .ToList().AsReadOnly()).

@dotnet/razor-compiler: I made a couple of changes to compiler code to facilitate the shift over to ImmutableArray<T>:

• The key change is in TagHelperParseTreeRewriter which previously held onto a List<KeyValuePair<string, string>>, which it handed out during tag helper binding before reusing the same collection later. In this change, it holds onto an ImmutableArray<KeyValuePair<string, string>>.Builder and returns a ImmutableArray<KeyValuePair<string, string>>. So, this represents a new allocation (for the underlying array) and copy that wasn't there before. However, I don't expect this will be significant and the code is simpler and a bit less surprising now.
• I unrolled the lambdas in TagHelperMatchingConventions.SatsifiesAttributes(...). IMO, this makes the code a bit more readable and takes advantage of the fact that ImmutableArray<T> is now in play, so it can foreach.

In Shared.Utilities, I made a few tweaks that I hope will be useful:

• PooledArrayBuilder<T> now has an enumerator.
• Added a KeyValuePair.Create(...) helper for NetFx and netstandard2.0, similar to the one on core.
• Added a HashSet<T>.AddRange(...) extension method to avoid boxing when passing an ImmutableArray<T>. Note: This is named differently that than HashSet<T>.UnionWith(...), which would normally be used to add multiple items to a hash set. Since UnionWith already exists as an instance method, the compiler won't consider similar extension methods of the same name when performing overload resolution.

[333fred]

Compiler and Shared changes generally look to me. One question.