Splitting XLinq classes into separate files.
Improve performance of enumerating empty collections.

Avoid perf hit from acquiring a reusable stack object to enumerate a collection that is empty, and thus requires no stack object.
This improves ImmutableSortedDictionary directly, and both ImmutableDictionary and ImmutableHashSet benefit as well since they use ImmutableSortedDictionary internally.
Remove or cache some unnecessary allocations
Remove unnecessary unsafe code flag.

The Immutable PCL targets platforms that include those that don't support unsafe code. Opening the solution in VS2015 results in a warning in the error list about this. But features that required unsafe code were recently removed so we don't need this flag any more.
Adding more details for how to build and test for the corefx repo
Fix tests to pass after perf improvement.
Exclude method used for perf trace collection from functional tests.
Switches object pool IDs from GUIDs to Int32.

This cuts out the expensive Guid.op_Equality step from ThrowDisposedIfNotOwned.
Add code comment.
Switch from locks to ThreadStatic for AllocFreeConcurrentStack.
Remove use of locks that significantly slow down enumeration.

Enumerating some immutable collections are necessarily slower than ordinary collections because they have to walk binary trees. But we needn't throw in locks into the enumerator and slow it down further in an attempt to claim enumerators are somehow thread-safe. They're not. And misusing them across threads concurrently would already lead to corruption.

By removing the locks here, we've significantly improved performance of enumerating ImmutableSortedDictionary (and the other binary tree based collections). Even though the locks weren't contested, they still took a significant chunk of time.

The loss of the locking means that technically if the enumerator is in use across multiple threads then now it's possible for a recycled Stack to still be in use on another thread, leading to data corruption for the possibly innocent subsequent user of that stack. Since we've already decided that immutable collections will not be considered as behind a security boundary (i.e. we won't treat such possibilities as security compromising to the core system), this seems quite reasonable for such an unlikely and unsupported pattern to carry this risk given the huge wins it has for all the supported cases.
Defend against pathalogical thread-safety case.

If SecureObjectPool.NewId were to execute in a concurrent scenario where one thread actually was suspended while other threads were allowed to increment the counter enough to go through all 32-bits of values and the timing happened to be _just write_, we could theoretically return UnassignedId. This fixes it by looping until we get it right.
Remove unnecessary ValidationStrings.resx file.

The resources in ValidationStrings.resx were not used anywhere, so I'm
just removing it as well as the coresponding designer support.
Added guards to ICollection.CopyTo implementations to avoid allocating the indices array for SetValue when the collection being copied from is empty
Use "this." in a few places to match the style of the project
Add indexer to ImmutableSortedSet`1+Builder class.

The indexer is available on the immutable type, so its absence from the Builder is notable. Fortunately, it's simple to correct.

New tests included.
Merge branch 'master' of https://github.com/Petermarcu/corefx
Merge branch 'lasekar/test2' of https://github.com/Priya91/corefx

Conflicts:
	src/System.Xml.XDocument/System.Xml.XDocument.csproj
Merge branch 'EnumerationPerfFixes' of https://github.com/AArnott/corefx
Merge branch 'MoreEnumerationPerfFixes' of https://github.com/AArnott/corefx