Support all binary payload APIs with only generics

[mtmk]

With this proposal we reduce the API footprint and make the default behaviour work as expected when sending byte types and strings:

await using var sub = await SubscribeAsync<T>(string subject);

await PublishAsync<T>(string subject, T data);

await PublishAsync(string subject); // send empty message / sentinel

The default serializer is smart enough to do the right thing handling known types avoiding surprises, especially when publishing.

// Send as binary data
await PublishAsync(string subject, new byte[] {1,2,3});
await PublishAsync(string subject, new Memory(bytes));
await PublishAsync(string subject, myMemory); // IMemoryOwner

// JSON serialized
await PublishAsync(string subject, complexObject);

The idea is to reduce the code duplication between generic calls and non-generic calls using binary data as payload and make the defaults work for the vast majority of the cases while having the flexibility of defining a custom serializer.

Related to #137

[mtmk]

Performance considerations for publish:

Without this change:

| Method             | Iter | Mean        | Error         | StdDev      | Gen0   | Allocated |
|------------------- |----- |------------:|--------------:|------------:|-------:|----------:|
| WaitUntilSentTrue  | 64   |  2,995.8 us |   1,481.06 us |    81.18 us |      - |    6987 B |
| WaitUntilSentFalse | 64   |    156.2 us |      21.80 us |     1.19 us |      - |     591 B |
| WaitUntilSentTrue  | 512  | 26,541.7 us | 115,608.79 us | 6,336.91 us |      - |   53614 B |
| WaitUntilSentFalse | 512  |    439.3 us |      63.39 us |     3.47 us | 0.4883 |    9575 B |
| WaitUntilSentTrue  | 1024 | 45,792.0 us |  29,602.46 us | 1,622.61 us |      - |  106941 B |
| WaitUntilSentFalse | 1024 |    711.4 us |      64.15 us |     3.52 us | 2.9297 |   46649 B |

With this change:

| Method             | Iter | Mean        | Error        | StdDev      | Gen0   | Allocated |
|------------------- |----- |------------:|-------------:|------------:|-------:|----------:|
| WaitUntilSentTrue  | 64   |  2,894.7 us |  1,268.27 us |    69.52 us |      - |    6990 B |
| WaitUntilSentFalse | 64   |    161.6 us |     23.09 us |     1.27 us |      - |     520 B |
| WaitUntilSentTrue  | 512  | 21,691.3 us | 11,121.19 us |   609.59 us |      - |   53606 B |
| WaitUntilSentFalse | 512  |    438.5 us |     70.65 us |     3.87 us | 0.4883 |   10168 B |
| WaitUntilSentTrue  | 1024 | 44,436.2 us | 37,207.27 us | 2,039.46 us |      - |  106921 B |
| WaitUntilSentFalse | 1024 |    738.8 us |    111.61 us |     6.12 us | 2.9297 |   44885 B |

[caleblloyd]

Excellent! I really like how it simplifies the codebase.

Left one comment, but don't let that hold up merging this PR

[caleblloyd]

Why is the null-forgiving operator needed here? Is SubscribeAsync<T> eventually returning T? instead? Would be nice if we could avoid that

[mtmk]

Default values in general yield empty/sentinel payloads that's why there are T?s in a lot of places. Do you think we shouldn't allow nulls? How would we handle sending and receiving empty payloads?

[caleblloyd]

True, I guess there is no way to avoid it for reference types when default may be retruned. Seeing as System.Text.JSON even does it