Fix #371

This PR adds a VecView<T> struct that is !Sized and wraps a Vec<T, N>, providing the same functionality (except those that require taking the vec by-value). It also makes the implementation for all methods on Vec<T, N> delegate to the VecView implementation, reducing the need for monomorphised code for each value of N used.

Example:

let mut v: Vec::<u8, 10> = [1,2,3,4].into_iter().collect();
let view: &mut VecView<u8> = v.as_mut_view();
view.push(5);

This change should brings the following benefits:

Better binaries

• Faster compile times: since less functions are monomorphized less code needs to be optimized and the compile time should be faster (not yet benchmarked)
• Smaller binaries: similarly, less monomorphized code should also lead to less code overall. On the Nitrokey 3 firmware we observed a small benefit (0.2%), by just using this patch, but I believe there are more gains to be had if we start explicitly using this pattern in our own code, for example in heapless-bytes too and then everywhere else.

Better ergonomics

Since Vec always requires the N to be specified, this makes generic code much less convenient.
For example a lot of our firmware write responses to buffers passed by the caller. To make that code generic implies having functions like:

fn respond<const R: usize>(&mut self, request: &[u8], reply: &mut Vec<u8; N>)

With this PR it could instead become:

fn respond(&mut self, request: &[u8], reply: &mut VecView<u8>)

Which is much simpler to use.

This also allows using this method in a trait with sacrificing object safety. This is the main driver for this feature, before the binary/compile-time improvements.

TODO

• Implement missing traits for VecVIew
• Document VecView
• De-duplicate the documentation between VecView and Vec. In the PR all methods are documented twice, this could lead to the docs getting out of sync. Soluctions could be to implement the functionality on VecInner and use a macro to generate the method for both Vec and VecView, or having one of the documentation refer to the other.
• Implement this pattern for other data structures. Nitrokey only uses the Vec of heapless, but it is certain that other consumers of this crate could benefit from the same gains for other structures in heapless.
• Make sure that the current approach can be adapted in the future with the CoerceUnsized traits.
  I'm not sure about this one because the traits are unstable, but I would aim for the possibility of coercing a Vec into a VecView with the same ease as it is to convert a &[T; N] to a &[T]. I don't really know where the language is going with this and whether the #[repr(transparent)] wrapper could turn out to be a blocker for that functionality.