Further reduce allocations in SemanticToken calculations

[ToddGrun]

Instead of realizing ImmutableArrays in several codepaths, we can instead just have the calculations append items to an existing list.

Also, in ConvertSemanticRangesToSemanticTokensData, switches to optimistically allocating an int[] instead of a pooled list for two reasons:

1. In almost all cases, the correct size is calculated before population
2. The pooled list that was being created commonly ended up being too large to be placed back in the pool, so we would end up losing both that list and it's backing array to GC.

This wasn't a huge memory hitter for me in the profile I'm looking at, but still is ~0.6% of allocations in the RoslynCodeAnalysisService process during the C#/html completions in the razor cohosting speedometer test.

Test insertion: https://dev.azure.com/devdiv/DevDiv/_git/VS/pullrequest/669091

Numbers looked good in the test insertion: SemanticRange[] allocations pretty much gone, and the int[] allocations in ConvertSemanticRangesToSemanticTokensData are down significantly too.

[davidwengier]

Other than the build errors and some naming tweaks, this makes sense to me.

[ToddGrun]

Test insertion run from commit 4 didn't have expected gains. Looks like the test is using a larger page than I was testing against. Switched to a custom pool which should work better against larger sematic token request. Test insertion queued for new numbers.

[ToddGrun]

@DustinCampbell -- I think I liked every single suggestion you made! Thanks!

[DustinCampbell]

🚀