This is a follow-up to #146 and #160. This makes the API surface even larger, but I think it may be worth it, any feedback is welcome!

Initially, I didn't plan to add those methods, but I wanted to add some convenience helper functions to reduce boilerplate code like this:

let chunk = consumer.read_chunk(data.len()).unwrap();
let (first, second) = chunk.as_slices();
let mid = first.len();
result[..mid].copy_from_slice(first);
result[mid..].copy_from_slice(second);
chunk.commit_all();

I implemented copy_to_slice() and copy_from_slice() methods on the different "chunk" types, which reduces above code to:

consumer.read_chunk(result.len()).unwrap().copy_to_slice(&mut result);

But then I realized that this is still a bit too convoluted, and instead of creating helper methods on the "chunk" types, I might as well add helper methods to producer/consumer, which would lead to code like this:

consumer.pop_entire_slice(&mut result).unwrap();

Instead of panicking if there are too few available slots, .unwrap() can be removed and the ChunkError can be handled as usual.

I think this is much more straightforward, and I like it more.

However, this adds more "push/pop slice" methods, which might be confusing. But OTOH, by naming them more explicitly, it might even be less confusing with regards to whether a whole slice is copied or only part of a slice (if there are not enough slots left):

• push_partial_slice()
• push_entire_slice()
• pop_partial_slice()
• pop_entire_slice()

Any opinions on this?
Is this more confusing or more clarifying?

Regarding implementation, I decided to implement the "entire" variant and use that in the implementation of the "partial" variant. It would also work the other way round (and I tried that as well), but I think the implementation is more straightforward this way.

Benchmark results are inconclusive, there are minor regressions and some improvements in the various benchmarks. I think it is close to the measurement uncertainty.