* Initial IPv6 connection support

TL;DR: We previously did IP:Port parsing based on splitting at the semicolon...that's pretty hostile for IPv6 and breaks everything. This adopts better parsing from Microsoft.AspNetCore since it doesn't exist in the BCL. The BCL/API conversation is started here: https://github.com/dotnet/corefx/issues/23463

A quick way to test this across all tests is via TestConfig, for example:
{
  "MasterServer": "[::1]",
  "SlaveServer": "[::1]",
  "SecureServer": "[::1]"
}

Note: there's still an Unspecified == AddressFamily.InterNetwork in SocketManager which may be affecting DNS endpoints that are v6...need to look at that next. This change allows actually connecting to an IPv6 endpoint via IP though, that's step 1.

* Move BasicStringGetPerf to non-parallel

* Fix IPv4 assumptions

The socket world has changed - unspecified and dual mode sockets now handle IPv6 correctly. We can just straight up remove the assumption of IPv4 anywhere in code now.

Since this is a race/thread pool thing, we should wait and see if the messges come through rather than assuming any specific time period. This gives more lead time (still capped) while completing the test as fast as possible.

Lots of documentation and formatting fixes, no functional changes.

This is no lonkger flaky...light the test up for Release as well.

include counters from GetOutstandingCount when reporting WriteResult.TimeoutBeforeWrite; include a "what were you doing?" when reporting certain ProtocolFailure exceptions; also, make the IDE happier

rename GetCommands() back to FinishProfiling() (akin to v1); add some obvious methods that avoid LINQ-to-Objects in a few cases, exploiting the fact that we can calculate the count as we reverse the list

move performance completion to start of message completion; fix bug that resurrected result-box; add async profiled test; make all timestamps not throw on duplicates; fake the response received if message aborted (otherwise values can be nonsensical); add aysnc profiled test

Completely rewrite the profiling public API, so that all the external consumer sees is a function that may provide profiling sessions; everything else is the caller's issue; remove all extraneous profiler tracking from the lib

make sure PhysicalConnection doesn't root the multiplexer; this, however, means that every check to the bridge needs to be null-checked

This sets a proper RedisException on the Message, but has the core exception as InnerException as you'd expect.

This also means the Message will have the info we add to it, rather than *sometimes* having it.

Race here

Lines up with behaviors elsewhere - we already have semantics for failures here...following along.

This is generally yhe behavior we want I think.

This is to ensure assumptions are correct. I believe what's happening if we're re-fetching the tie breaker key on a background interval which is landing in the profiler on the multiplexer. This likely the same symptom is affecting several tests. For example, LowAllocationEnumerable.

If this is correct, we should likely find a way to exclude the tie breaker (and any heartbeat activities) from the profiler...or give the profiler an option, but this would require changing the interface (bad) or we add info to a profiled command to indicate. Or we decide this is proper behavior (profiling everything) and we move the tests off DB 0 or something so we can easily exclude the tiebreaker GET.

Before these were left in the scheduler on every success, which piles up needlessly. This cancels them upon success.

It's only needed for a few tests, what we were doing was drastic overkill, especially with background concurrent GC in play these days.

This is mainly around proper FireAndForget as well as .Wait() elimination. More to do but this is a big first pass.