Add const-erased versions of the various containers

[sosthene-nitrokey]

Making code flexible around heapless structures can be a bit verbose because it requires being generic over the capacity of each collection. This could be helped by providing versions of the structures with the const erased. This would allow removing the generics in some cases.

For example, heapless::Vec currently is :

pub struct Vec<T, const N: usize> {
    len: usize,
    buffer: [MaybeUninit<T>; N],
}

It should be possible to provide a struct that goes hand in hand with it:

pub struct VecView<'a, T> {
    len: &'a mut len,
    buffer: &mut [MaybeUninit<T>],
}

impl<T, const N: usize> Vec<T, N> {
    fn as_view(&mut self) -> VecView<'_, T> {
        VecView { len: &mut self.len, buffer: &mut self.buffer }
    }
}

With VecView implementing most of the API that Vec currently implements. This would allow for example methods that write data to an outbuffer of type &mut Vec<T, N> to instead take a parameter VecView<'_, T>.

Something like:

fn do_something<const N: usize>(response_buffer: &mut Vec<u8, N>)

could become

fn do_something(response_buffer: VecView<'_, u8>)

In a trait for example this would also have the advantage of making it object-safe.

I believe this pattern:

1. Improve ergonomics
2. Might reduce compilation time and binary size because of monomorphisation (unverified)

[sosthene-nitrokey]

Types:

• Vec
  • VecView: Implement serialize #453
  • Vec: add a "View" that can mutate the vec and erase the const generic. #425
  • Use macros to implement traits for Vec and VecView. #451
  • VecView: fix memory leak of drop #465
• String
  • String: implement StringView on top of #486 #487
• Deque
  • Implement DequeView on top of #486 #490
• LinearMap
  • LinearMap: add LinearMapView, similar to VecView on top of #486 #491
• HistoryBuffer
  • Implement HistoryBufferView on top of #486 #493
• BinaryHeap
  • BinaryHeap: implement BinaryHeapView on top of #486 #495
• MpMcQueue
  • MpMcQueue: add MpMcQueueView, similar to VecView on top of #486 #488
• SortedLinkedList
  • For this one it might also be interesting to erase the Idx generic at the same time, though it would likely be a challenge.
  • SortedLinkedList: add SortedLinkedListView, similar to VecView on top of #486 #497
• spsc::Queue
  • Queue: implement QueueView on top of #486 #496

IndexMap and IndexSet

IndexSet depends on the View type for IndexMap being available.

IndexMap is currently implemented with a CoreMaptype that looks like:

struct CoreMap<K, V, const N: usize> {
    entries: Vec<Bucket<K, V>, N>,
    indices: [Option<Pos>; N],
}

It is not possible to construct a View for this type like for Vec since the N would have to be erased twice.

We could solve that issue by "inlining" the indices into the entries:

struct CoreMap<K, V, const N: usize> {
    entries_indices: [(MaybeUninit<Bucket<K, V>>, Option<Pos>); N],
    len: usize,
}

Then only one N needs to be erased, and this can be implemented. However this requires changing the implementation significantly.

It might even be possible to get rid of the len field (I think an entry is initialized if and only if a index points to it, and only one index can point to it at a given time?).

[sosthene-nitrokey]

There are cases where some adjacent structures have the const generic that could be removed thanks to this implementation. Would it be worth making breaking changes to remove this const generic?