Expand Sink abstraction to handle/hide uninitialized data

[arthurprs]

In order to safe guard against UB (Undefined Behavior) and safety issues (exposing uninitialized data) the Sink abstraction is expanded to handle uninitialized data safely.

Other alternatives were explored (eg. Sink trait) and the alternative in this PR did show just as good performance but with less code churn and compile time impact.

Sink changes

• Move Sink abstraction and related bits to its own module.
• Sink safety invariant is that it never exposes uninitialized data.
• Add additional methods to Sink (eg. extend_from_within) that can safely operate over possibly uninitialized byte slices internally.

New VecSink

• Add VecSink wrapper which can be used to create Sinks over possibly uninitialized Vec data.
• On drop VecSink will adjust the backing Vec length to cover the then initialized bytes.

Unsafe Compression changes

• write_u* functions now use core::ptr::write so they can safely operate on uninitialized data.

Safe compression changes

• Safe wild copies now use Sink::extend_from_slice_wild so they can safely operate on uninitialized bytes.

Safe Decompression changes

• The previous 16 byte wild copy in the slow path didn't play well with the new Sink as it could expose uninitialized bytes temporarily (which now panics). It was replaced with fast-paths + fallback which performs equally or better (eg. 66KB Json dataset).

Unsafe FrameDecoder changes

• Similar to the safe FrameDecoder, decoding a block is now required to initialize the byte buffer passed to the underlying Read::read method. This will be improved when Read::read_buf is stabilized.

Fixes #19

[arthurprs]

Sink is back hehe

Yeah :smile:

Thanks for that, I had no time to tackle this, since I was quite busy relocating.

I'm no stranger to relocation, it's hard.

[arthurprs]

Superseded by #22