Need stronger rationale for not using span<byte>

[akrzemi1]

The "Span reflex" article criticizes two "reflex" opinions:

1. Using std::span<std::byte> for representing single buffers
2. Using std::span<std::span<std::byte>> for representing ranges of buffers.

While I agree with the criticism of #2, the criticism of #1 looks insufficiently founded in the context of Capy.

In Capy, we have a concrete type const_buffer with the following contract:

1. On one side, there is a set of factory functions that make a const_buffer form any recognizable range of trivially-copyable structures (including char).
2. On the other side, there are framework functions, that knowhow to convert a const_buffer to an iovec or WSABUF.

It looks like using std::span<const std::byte> instead of const_buffer (or making const_buffer an alias for std::span<const std::byte>.

It is true that std::byte unnecessarily gives provision to do byte-shifting operations, but who cares, when the only thing the users do with this type is to create it via capy::make_buffer and pass it to framework functions, which will now how to translate to iovec or WSABUF.

And the benefit of using std::span<const std::byte> is not having to introduce another type that the users have to learn.

Having a distinct type to indicate a minimally narrower contract makes sense in general, but is inconsistent with other decisions in Capy: all async operations return std::tuple<std::error_code, ...> even though there are special rules and relationships that apply to tuple elements.

The choice to introduce a new type would be clearer if const_buffer offered implicit conversions from every known sequence of trivially-copyable elements (what capy::make_buffer currently does), but this is not the case.