Changed RandomRangedNumberGenerator multi-threading test to use PLINQ

Related to #227, I've eliminated ````CreateReturnsUniqueNumbersOnMultipleCallsAsynchronously```` and replaced it with ````CreateDoesNotThrowWhenAccessedAcrossThreads```` that steals from @adamchester's suggestions in an effort to lower the unit test time in ````RandomRangedNumberGeneratorTest````.

All my testing was done on a machine with 2 cores.  

First, I did observe the PLINQ-version test fail for values of ````numberOfThreads```` in [5, 10, 20].  However, it fails at a much lower rate then the original test.  With the lock removed from ````RandomRangedNumberGenerator````, the observed failure rate of the original test was 100% . I observed the new test failing around 20-30% of the time (2-3 times out of 10 runs per each thread count).  

Next, despite having assertions that verified both an exception not being thrown as well as distinct values properly being created, all failures of both versions that I observed always failed due to a thrown exception.  The specific exception being thrown is an ````InvalidCastException```` in both versions (although wrapped in ````AggregateException```` in the PLINQ version).  As such, I eliminated the assertions around distinct created values from the new test and that compelled the test rename since I was only verifying the lack of an exception.

Lastly, in terms of performance, the new version is faster in a direct (albeit slightly unfair) comparison with the original.  The original test (when executed against a properly thread-safe implementation), generally took between 1 and 2 seconds to complete.  The new version took between 120 and 130 ms on average.  I could achieve that performance in the original test by cutting down the ````timesToTry```` parameter quite severely and removing the multiple test cases so this isn't exactly apples to apples.  However, the PLINQ version also has readability on it side.  This performance puts the new test solidly in the low-end "Medium" category, I have never seen it pass in less than 100 ms or greater than 200ms.  There seem to be 2 other tests that generally fall into that same category.

I'm not sure if this improvement is "good enough" or if I missed an opportunity to make it faster or clearer, but this seemed like the appropriate point to submit it for feedback on those points.