Suggestion: debug-assert that the allocator returns aligned memory

If the global allocator returns unaligned memory, the standard library catches it very late. Take this code:

#[global_allocator]
static GLOBAL: AccountingAllocator<mimalloc::MiMalloc> =
    AccountingAllocator::new(mimalloc::MiMalloc);

#[repr(C, align(256))]
pub struct BigStruct { … }

fn collect() {
    assert_eq!(align_of::<BigStruct>(), 256);
    assert_eq!(size_of::<BigStruct>(), 256);
    let vec: Vec<T> = std::iter::once(BigStruct{…}).collect();
    dbg!(vec.as_ptr() as usize % std::mem::align_of::<T>()); // Sometimes prints 64
    let slice = vec.as_slice(); // panics in debug builds with:
    // 'unsafe precondition(s) violated: slice::from_raw_parts requires the pointer to be aligned and non-null, and the total size of the slice not to exceed `isize::MAX`'
}

Because of a bug in MiMalloc, the Vec gets non-aligned memory.
This is not discovered until vec.as_slice calls slice::from_raw_parts which has a debug-assert.

I spent a lot of time looking for this bug before I realized it was MiMalloc that was to blame.

I suggest we add a debug-assert the standard library to check that the allocator returns aligned memory, i.e. here:

https://github.com/rust-lang/rust/blob/8885239786c9efe5c6077de65536a5e092e34a55/library/alloc/src/raw_vec.rs#L442-L478

That would then report "The global allocator returned non-aligned memory", directly pointing the user at the problem, saving a lol of time for the next person.

Start by reading library/alloc/src/raw_vec.rs around lines 442-478 and compare the allocator behavior in the provided global-allocator reproducer. Verify the unaligned allocation scenario and determine how the diagnostic should identify the global allocator. Done means the failure is detected there with a clear message pointing to the allocator problem.