Add an Arc-/Rc-based reader

[fitzgen]

https://www.reddit.com/r/rust/comments/8fcm5i/a_sampling_cpu_profiler_for_linux_written_in_rust/dy2mm2a/?context=3

3. The EndianBuf does take a lifetime, which is somewhat annoying when you want to just mmap a file and you don't want to permanently leak it. What I did here (for now) is I've put everything into one structure (FrameDescriptions in frame_descriptions.rs), put the mmaped data in an Arc, wrapped everything in mem::ManuallyDrop, set the lifetimes to 'static and used mem::transmute quite liberally.

I think we don't want to just make EndianBuf but with replacing the &[u8] with Arc<[u8]>, because that means that slicing or splitting the reader would require copying the data. We want something like (start, end, Arc<[u8]>) and have slicing/splitting just change the start and end indices and bump the ref count.

cc @koute

[philipc]

I'm going to look into using https://crates.io/crates/bytes (or at least use its ideas).

[fitzgen]

https://carllerche.github.io/bytes/src/bytes/bytes.rs.html#155-295 seems relevant

[fitzgen]

It seems that it is similar to the (start, end, Arc<[u8]>) representation but with variants for static buffers (I don't think this is too relevant for our use case) and for inlining small buffers directly into the handle instead of putting them behind a pointer.

[koute]

If I'll mmap a file I'll have some Arc<T> instead of an Arc<[u8]>, where T is going to be an arbitrary type which will control the lifetime of the mmap. So it'd be the best to allow the user to use a custom type and constraint T to be T: Deref<[u8]> or T: bytes::Buf or something along these lines.

[fitzgen]

SGTM!

[fitzgen]

Some initial ground work being laid in #295