Remove allocations from Keys/Values/ContainsValue members

Several methods in the immutable collections library use LINQ and incur more allocation than is necessary.  In particular, several types’ Keys and Values properties as well as their ContainsValue methods can be optimized to avoid multiple unnecessary allocations.

For example, ImmutableDictionary<TKey, TValue>.ContainsValue(TValue) is implemented today to get this.Values and then call LINQ’s Contains on that result.  This results in an allocation for the Values enumerable (which, as with all C# iterators, has an optimization to also double as enumerator when possible), but since the dictionary also provides an allocation-free enumerator, we can simply open code the enumeration, making ContainsValue allocation-free as well.

The worst offender this PR fixes is ImmutableDictionary<TKey, TValue>.Builder.Values, which is implemented with the code “return this.root.Values.SelectMany(b => b).Select(kv => kv.Value).ToArray(this.Count)”.  This results in upwards of five allocations plus two allocations per HashBucket in the dictionary (so a dictionary with 100 items could very well incur over 200 allocations to enumerate via the builder’s Keys/Values)!  A similar fix brings it down to just one allocation, for the enumerable. (The removal of the ToArray method does change the semantics slightly, so it could be put back if really desired, but it’s unclear why those semantics were desired, and the corresponding Keys property doesn’t have such a ToArray call, so it appears to not be by design.)

The decrease in allocation and LINQ usage also has a measurable impact on throughput, e.g. perf of ImmutableDictionary<TKey, TValue>.ContainsValue improves by ~10%, perf of enumerating ImmutableDictionary<TKey, TValue>.Builder.Values improves by ~20%, etc.

(This PR is orthogonal to #147 and can be merged independently.)