* Add UNLINK as .KeyUnlink()

Submitting as a PR so test as reuable, but maybe we want this as an overload via some enum on .KeyDelete() instead? I'm good either way, but getting the ball rolling on #909 here.

* Add feature check for UNLINK

Ah right, 4.0.0+ only...

* Move UNLINK behind KeyDelete() and always call it if available

We still weren't testing Delete(Async)() in general, so tests added there. I've confirmed this is running DEL against 3.x and UNLINK against 5.x.

* Move GetDeleteCommand after the methods (consistent with rest of the file)

Not 100% sure this is what we figured out, but good first pass at getting there if not.

* Eliminate the need for Stream magic strings & added additional XGROUP subcommands.

- Replaced the need for magic strings with Range, ReadOffset, and GroupReadOffset structs.
- Condensed some of the method signatures due to the new structs.
- Added methods & tests for two of the XGROUP subcommands (DESTROY & DELCONSUMER).

* Updated tests with their original IDs used.

* Use a single struct to represent stream position for Group, Read, and ReadGroup commands.

- Consolidated GroupCreateOptions, GroupReadOffset, and ReadOffset into a single struct, Position.
- Removed the "Pair" structs and created StreamPosition, this will be used in the multi-stream read commands.
- Renamed RedisStreamEntry to StreamEntry.
- Also added the remaining subcommand for the XGROUP command (SETID) and an associated unit test.

* File cleanup, delete consolidated structs.

* Additional changes and unit tests for the Position struct.

* Update PositionKind enum with explicit zero value.

These need changes in assumptions to match current behaviors. We don't account for what the instant debug abort should do.

We'll be using BenchmarkDotNet for this going forward

This is likely causing some fail as we're not sure everything has been sent. If we *can* be sure, it'd be safe to close it early, otherwise we need to eat the TIME_WAIT.

Buuuuuuut now that I think about it. Linger only works inherently *when there's data left to write*. If our data is *in the pipe* and not yet *in the socket buffer*, we'd be killing it early. This may explain several failures, especially inconsistent and under-load ones.

We really need to figure out how to best close the socket *when the pipe is done* in the Dispose() case. /cc @mgravell

add TEST tracers when connecting and closing; prefer PING on subscribers; avoid NRE in connect; set no-linger