Introduced thread-affine CultureInfo cache

[mrange]

Caches CultureInfo per Thread in order to improve DateTime parsing when parsing with specific Culture

The idea for this optimization started from this StackOverflow question: https://stackoverflow.com/questions/42469637/

Performance numbers:

Parsing 100000 dates
Using cached CultureInfo object...
took 114 ms
Using updated TextRuntime.GetCulture...
took 144 ms
Using fresh CultureInfo object (same technique as old TextRuntime.GetCulture)...
took 52556 ms

[ovatsus]

Thanks

[mrange]

That was quick... I just like to point out that since I have gone all in VS2017 I haven't been able to compile the type provider locally. However, I have tested the functions that were causing problems in the stackoverflow post and they seem to perform a lot faster now (~50x)

[rmunn]

Another possible solution might be to leverage the CultureInfo.GetCultureInfo static method, which is documented as being cached already, avoiding the need to create and use our own cache. The only pitfall with that method is that it will return the invariant culture if its argument is an empty string, but it will throw an exception (!) if its argument is null. (Why, C#, why?!?)

So a simple defaultArg cultureStr "" followed by a call to CultureInfo.GetCultureInfo should be enough, and it would certainly be simpler than the "implement our own cache" taken in this PR.

[mrange]

CultureInfo.GetCultureInfo uses a synchronized HashTable under the hood but looking more closely at the implementation reveals that lookups are look-free which is good. "Unfortunately" it also does .AnsiToLower which will add some kind of GC pressure but probably not that much.

So I think it makes sense to use CultureInfo.GetCultureInfo instead however in order to preserve the semantics of TextRuntime.GetCulture we still need the test String.IsNullOrWhiteSpace cultureStr because this throws: CultureInfo.GetCultureInfo " " where this returns invariant culture: TextRuntime.GetCulture " "