While the addition of MessagePackPrimitives is proving challenging (ref: #1986),
what's really needed for practical use cases is the ability to Write/Read to/from Span.

For example, in my network framework MagicOnion, while we're reading and writing headers in MessagePack binary format, there are cases where we want to read/write directly with Span.

Therefore, I adapted MessagePackWriter and MessagePackReader to support Span operations.
Since the Writer is expected to auto-expand, I made it throw an InvalidOperationException when expansion is needed.
While Try-pattern APIs might be better, this current approach isn't necessarily bad.

I also added a public long WrittenCount property since we need to be able to get the amount written.

For the Reader, since some APIs in SequenceReader require a Sequence, I temporarily implemented it to create a Sequence using ToArray.
While this is better than throwing an exception, it's not the optimal solution.

Additionally, since ReadBytes requires generating a ReadOnlySequence, I added TryReadBytes that returns a raw Span.
This should be a required API for symmetry, as TryReadStringSpan already exists.

Making MessagePackReader compatible with ReadOnlySpan enables the addition of MessagePackSerializer.Deserialize<T>(ReadOnlySpan<byte>), though this API isn't included in this PR.
The inability to pass Span to Deserialize is a shortcoming in MessagePack for C#'s API that needs to be addressed.

Note that when both ReadOnlySpan and ReadOnlyMemory overloads exist, passing a byte[] causes overload resolution errors, so we need to either add T[] overloads or resolve it with OverloadResolutionPriority (though the latter is likely impractical).

More advanced solution proposal:
Remove ReadOnlySequence generation from BufferReader's public API to make everything Span-based. This would eliminate the need for Span copying and allow removing ReadOnlyMemory from overloads (though it might need to be kept for compatibility reasons).