Avoid boxing ImmutableHashSet<T>.Enumerator.

This introduces a pattern that can be applied anywhere to conveniently avoid boxing one's own Enumerator struct without duplicating the body of foreach loops everywhere.
Slight syntax touch-ups in response to feedback.
Remove erroneous use of GetEnumerable.

Its use on HashSet<T> is not necessary. The local variable is already strongly typed and will get the struct enumerator. In fact GetEnumerable would have made this code worse.
Fix handling of IDisposable enumerator structs.

In adding code to opt-in ImmutableArray to the GetEnumerable extension method, I noticed it didn't work because ImmutableArray`1+Enumerator didn't implement IEnumerator<T> (because it doesn't want to be disposable to reduce code gen size). This called to my attention that the EnumeratorAdapter`2 type didn't implement IDisposable itself, so it would not recycle the stacks used by our several AVL-tree based collection's stack objects used by their enumerator structs.

To fix this, I introduced DisposableEnumeratorAdapter. So we have adapter structs for both cases: disposable and not disposable. Since C# doesn't allow overloads of methods that vary only on generic type argument constraints, this requires that the caller of the extension methods call the right method for their struct type. I've put a constraint on one method and a debug.assert on the other method to help flow callers into the right buckets and verified that a mistake produces either a compile error or a test failure.

I stop short of actually opting ImmutableArray<T> into the pattern (in this commit anyway) because it caused test failures since the types of exceptions thrown from uninitialized ImmutableArray<T> structs changed (due to calling a different GetEnumerator method).
Apply enumeration enhancement to ImmutableSortedSet<T>
Apply enum pattern to ImmutableList<T>

It turns out it only applies in one place. But as it is RemoveRange and if it has an empty list as an argument we'd like it to be fast, it seems worthwhile.
Remove Xunit nuget package references from Tests.props
Merge pull request #223 from AArnott/fix211

Avoid boxing ImmutableHashSet<T>.Enumerator and others
Added System.Text.RegularExpressions source
Fix some XML comments
Merge pull request #227 from mellinoe/add-regex

Added System.Text.RegularExpressions source
Update README.md

Added Regular Expressions description
Merge pull request #225 from krwq/removePackagesReferencesFromTestsProps

Remove Xunit nuget package references from Tests.props
Merge pull request #226 from alfaproject/xml-comments

Fix some XML comments
Improve performance of Regex ctor and IsMatch

The Regex class maintains a cache of byte codes, which the Regex ctor indexes into using a key.  It uses this seemingly innocuous line to create that key:

String key = ((int)options).ToString(NumberFormatInfo.InvariantInfo) + ":" + cultureKey + ":" + pattern;

This, however, has the unfortunate effect of allocating a string for the options, a string array for the five strings to be passed to the String.Concat call generated by the compiler, another string array allocation inside of Concat, and then the resulting string for the whole operation.  The cost of those allocations is causing a non-trivial slowdown for repeated Regex.IsMatch calls for simple regular expressions, such as for a phone number (e.g. "^\\d{3}-\\d{3}-\\d{4}$").

This commit adds a new struct key type that just stores the constitutent options, cultureKey, and pattern, rather than creating a string to store them.  That key is then what's stored in each entry in the cache.

For repeated Regex.IsMatch calls for basic regular expressions like the phone number one previously mentioned, on my machine this improves throughput by ~35%, in large part due to ~80% reduction in number of allocations, and (for this particular test case) an ~70% reduction in number of bytes allocated (it depends primarily on the length of the pattern and the length of the culture name).
Add Jenkins CI badges
Move NuGet.config up one level where VS can see it

NuGet.config files can be found by VS package restore so long as they're
in a parent directory of the sln.

Copy the file one level higher to align with that. Once the buildtools
are updated, the old copy can be deleted.
Merge pull request #233 from nguerrera/move-up-nuget-config

Move NuGet.config up one level where VS can see it
Remove superfluous ToLowerInvariant helper
Merge pull request #236 from alfaproject/tolowerinvariant

Remove superfluous ToLowerInvariant helper