Replaced lock with ConcurrentDictionary in RandomRangedNumberGenerator

As part of some unit test performance changes related to ````RandomRangedNumberGenerator````, it was discussed that we should consider replacing the lock with  ````ConcurrentDictionary````.  As a guinea pig, I used the ````CreateReturnsUniqueNumbersOnMultipleCallAsynchronously```` test that has the new PLINQ implementation.  I ran it 10 times with the lock in place for an average of ~340 ms.  After switching out the lock for a concurrent dictionary, I ran 20 more trials, 10 per overload of ````GetOrAdd````.  I observed an average test time of  320ms for the overload taking a valueFactory, so suggests it may be a bit more performant (obviously this was a limited number of trials).  From what I can tell based on the literature @adamchester provided, we could possibly expect a more significant difference on a machine with more cores (my test machine only has 2) due to how we're using the dictionary.

In case you're curious, the average test time for the overload taking an actual value was ~ 520ms, so far slower than either of the others.  That surprised me, I thought the delegate would be slower (if there was any difference).  This took less than an hour of effort so if it turns out this isn't a desired change and we want to keep the lock, not a ton of time spent.