Lots of cleanup here to make additional bits later more straightforward and less conflicting.

Same order where possible and eliminated the Browsable attribute diffrence with a shim instead.

After 50547eba, TaskSource.Create and TaskSource.CreateDenyExecSync methods are the same. There was some crud left everywhere that appeared like differences but it's really determined once in the static initializer for TaskSource based on the platform anyway.

I've fixed the tests as well - they were a bit backwards on logic/assumptions so hard to read, and have been failing for some time. Now we'd expect ContinueWithExecSync to *not* be hijacked, and everything else to be...that's how the tests are as well.

Note: the #if DEBUG change is because internals are already visible to tests...just simpler.

This doesn't resolve the issue, but adds several confirmations and more information. At the moment we're not recognizing :6380 as a slaved instance though it clearly is from the outside. There's more to dig into on recognition here. This just improves the test quite a bit, before it was throwing in the middle without much info.

This didn't prctically matter because they match with defaults...but was wrong.

This failed under unit test load due to unintended retries during periods where async continuations for completion of the test don't occur before retries kick in and change an auth exception to a socket exception (which we correctly already closed).

Still, I think we should consider storing the initial connection error seperately from others as there's a fundamental race of an error that an observer cannot see when retries overwrite the last error message.

Previously was allowing 0ms to actually get a broadcast

TODO: inherit from tests project and use a proper Skip.

Also fixes tests that go along with (failing previously due to a message change before this one).

These look at some global counters so can't depend on parallel bits - marking them as non-parallel.

This was correctly blowing up as we don't run that test server...ignore that with a valid server and test what we actually wanted to test.

Old test mismatched heartbeats under load - this is local and server test friendly.

This test was breaking in my timezone because it's already DST in Tokyo, but not here. I wish that was the lead in to a joke or something but...yeah no. FML.

This is a static init...it's not going to vary. We should probably drop net45 and just delete this whole concept from the code.

There's a VS runner bug in 2.4.0-beta.1, see https://github.com/xunit/xunit/pull/1643

* Add netstandard2.0 target to SE.Redis projects

Two new conditional compilation constants are introduced:

* FEATURE_PERFCOUNTER - supported in net45 and net46
* FEATURE_THREADPOOL - supported in net45, net46, and netstandard2.0

* Add netcoreapp2.0 target framework to test projects

* Replace CORE_CLR conditional compilation symbol

with built-in NETSTANDARD1_5 or NETCOREAPP1_0 since now netstandard2.0
is also supported.

* Remove unnecessary conditional compilation constants

* Give defaultClientName a value when it is null
This prevents calling TryGetAzureRoleInstanceIdNoThrow() repeatedly in the null case.
* Upgrade xunit to 2.3.1
* Upgrade xunit to v2.4.0-beta1 to work around https://github.com/xunit/xunit/issues/1601
* Move xUnit to 2.4.0-beta.1.build3958

The .NET Core documentations states that hte SetMinThreads Method is available in .NET Core 1.0+. Updated instructions to identify that. Also updated the link to the new documentation.