GC pressure caused by ContentItem allocations

[sharwell]

Opening Roslyn.sln on Visual Studio 2017 (15.3 Preview 6).

A total of 664MiB was allocated for ContentItem objects in PatternExpression.Match, contributing to GC-related delays while opening the solution. Two approaches can be used to attempt to reduce GC load here:

1. The method should be evaluated to determine the fraction of calls which end up returning null. If this fraction is relatively high, the method can be altered such that the ContentItem allocation is avoided in these cases.
2. If the above does not lead to a substantial reduction, ContentItem can be evaluated for transition to a value type (struct). This specific type would need to meet the following specific conditions in order for this to improve upon the current behavior:
   1. On average, the number of references to each ContentItem instance should not exceed 2. At two references per instance, the overhead of the value type equals that of the reference type.
   2. The type should not be boxed due to direct or indirect use as an object.

[sharwell]

⚠️ The above issue only reported allocations for ContentItem itself. An additional 2051MiB of allocations occurs for the Dictionary<string, string> it contains. If step 1 is used above to avoid the allocations of ContentItem altogether, this issue will be resolved at the same time. Otherwise, the map should be specifically evaluated to determine if it is generally empty. If so, replacing its use with an ImmutableDictionary<string, string> (which has a singleton Empty instance) would dramatically reduce the overall GC load caused by this type.