In some cases where the frames are particularly large, we may opt to
split them into smaller frames. This may be due to performance reasons
when transmitting data or it may be due to limitations like those of
compressors used to compact frames. So include a test case that we know
will get split to make sure it is handled correctly. Or at least make
sure we are catching errors that would cause it to be mishandled.

It appears that we are splitting frames in `serialize_byteslist` so that
we can compress them. However we are not merging them back together
afterwards during deserialization. This can cause an exception to be
raised by serializers that expected their frames to be structured in a
particular way.

To fix this, we make sure to call `merge_frames` after `decompress` in
`deserialize_bytes`. Further we make sure to pack the `lengths` of the
original `frames` in the `header` (if not already present) in
`serialize_byteslist`. This should ensure deserializers get the original
frame structuring back when they operate on them.

As using the `bytes` constructor will cause a copy (even if it is
provided a `bytes` object), special case handling a `bytes` object and
just return.

This is already handled in the check above.

This is already handled by the fast path for more than zero frames.