Optimize RedisValue / reader logic by using canonical parser and new ShortBlob storage kind

[mgravell]

Historically, only explicit integer and boolean results from the server (i.e. :42\r\n or #t\r\n) get special treatment - otherwise we just take the byte[] snapshot, which is alloc heavy if we're dealing with small values (we don't mind allocating when necessary, and there's Lease<byte> APIs for heavy scenarios - but let's avoid allocations for high volume trivial scenarios).

Example scenarios:

• get or hget on a value that contains a counter
• get or hget on a value that contains a short text string
• incrbyfloat (always returns $, even in RESP3)

Here, we introduce a new storage type (internal layout of RedisValue, packing 8 bytes into the overlapped/union field, and using a new sentinel that defines the size (so we don't lose any available payload bits).

If the value is longer than 8 bytes, we also check whether it is likely a canonical number, meaning: a long or double that round-trips cleanly without any ambiguity; in those cases we use the pre-existing raw storage.

Result:

• no allocations for values <= 8 bytes
• no allocations for values > 8 bytes that are reliably canonical long, ulong or double values
• otherwise, no change

As a side win: the RedisLiterals values now also check whether to use short-blob storage, which covers most of them.

All the usual semantics are otherwise preserved.