feat(bytes): Deprecate BytesList class

[aapoalas]

As part of std cleanup, this PR deprecates the BytesList class and suggests plain Uint8Array[] usage instead. The two non-deprecated users of this class are also transformed to use a plain Uint8Array[].

These are:

1. msgpack: Here the transformation is trivial and the bytes/concat function can be utilized directly.
2. DelimiterStream: Here the transformation is very much nontrivial.

DelimiterStream

Switching to a plain Array based approach made quite a few optimisations more directly "visible" in the stream implementation. These are in no particular order:

1. The generally expected case is that a chunk will include a delimiter. It's generally thus the case that the list of previous chunks is relatively short, and that at the end of a chunk's iteration all previous chunks will usually have been fully "forgotten" by the stream. This makes it a bit easier to reason about what is going on in the stream.
2. All chunks are always fully iterated, meaning that the iteration index is always a local property: At the start of a chunk's iteration it is at the beginning of that chunk and at the end it is at its end. There is no need to keep it in-between iterations.
3. Match index only needs to be "persisted" at the end of the chunk iteration. Otherwise it can be a purely local variable.
4. Controversial / uncertain / API contract change: If a particular slice of data is coming from a single chunk, then there is no strict need to reallocate memory if we trust that the buffers we've been given are "ours" to give. This means that the buffers that our DelimiterStream outputs may be sub-views of (or direct references to) the buffers that it has been given, and any consumers should consider themselves free to touch or mutate only those sub-views they've been given. This is likely a fair performance boost, but it does mean that the API contract is much more strict suddenly.

closes #3549
part of #3489

[CLAassistant]

All committers have signed the CLA.

[aapoalas]

comment: Kind of an obvious downside here: I've written out all the possible cases in excruciating detail to optimise each of them individually, and added a fair bit of comments. The number of lines has gone way up.

[kt3k]

I think lower level utilities like DelimiterStream should be optimized for performance rather than ergonomics. The changes in it look fair and reasonable to me. LGTM

[johnspurlock]

Heads up - this seems to have broken DelimiterStream: see #3609