Fix UB in pop/push under Stacked Borrows

[ryanavella]

cargo miri test reports that Vec32::pop and Vec32::push have UB under the Stacked Borrows model.

The UB occurs when a pointer is used to read/write out-of-bounds of the slice it was created from. This slice is conjured by auto-deref of self in both implementations.

mediumvec/src/vec32.rs

Lines 113 to 114 in 398db61

	self.len -= 1;
	Some(ptr::read(self.get_unchecked(self.len as usize)))

mediumvec/src/vec32.rs

Lines 101 to 103 in 398db61

	let end = self.as_mut_ptr().offset(self.len as isize);
	ptr::write(end, value);
	self.len += 1;

In other words, we are dealing with a variant of rust-lang/unsafe-code-guidelines#134

This PR silences miri by explicitly going through pointers so that we don't accidentally retag and reduce the provenance.

[mbrubeck]

Thank you!

[ryanavella]

@mbrubeck Just had a related thought, I know it is typical for authors to yank crate versions with UB but I'm not sure if it is worth yanking here. Miri passes cleanly with -Zmiri-tree-borrows.

Interestingly though, cargo test (no miri) on old versions of mediumvec panics with the following:

thread 'vec32::tests::it_works' panicked at core\src\panicking.rs:223:5:
unsafe precondition(s) violated: slice::get_unchecked requires that the index is within the slice
stack backtrace:
...
   6: mediumvec::vec32::Vec32<i32>::pop<i32>
             at .\src\vec32.rs:114
...

I think the std folks added a new debug_assert! precondition in slice::get_unchecked? This definitely didn't panic before, but it started to introduce panics in my production code.

Again, probably not worthy of yanking old versions, but I thought I'd let you know that I'm currently locally patching mediumvec until a new release is cut.

[mbrubeck]

I have released mediumvec 1.3.1 with this fix.

I don’t see a major benefit of yanking old versions here.