Switch `BackingBuffer::VirtualMemory` to Safe `Box<[u8]>` Backing

[Barca545]

Motivation

This PR addresses concerns raised in #359 about the safety and maintainability of manually managed virtual memory using NonNull<u8> and pointer arithmetic. By switching to Box<[u8]>, we maintain similar memory semantics while gaining safety and reducing code complexity.

Changes

Main Changes

• Used a Box<[u8]> for the contents of BackingBuffer::VirtualMemory instead of a NonNull.
• Unsafe blocks are now limited to system-level allocation/deallocation and bounds-checked access is the default.
• Removed most manual pointer arithmetic and unsafe dereferencing in favor of slice indexing.
• Switching to Box<[u8]> also allowed me to remove the text field from GapBuffer which reduces the size of the struct.

Miscellaneous changes

• Pinned down the toolchain to nightly-2025-04-15 as not all features required to build this crate are available on all versions of nightly.
• Added line to clarify virtual_release returns memory which will error if accessed before committed.

Results

Benchmarks were obtained by running cargo bench --bench lib -- --save-baseline before on main and cargo bench --bench lib -- --save-baseline box-raw-alloc on my branch. Results were then exported to JSON and compared using critcmp before.json box-raw-alloc.json --list. See before.json and box-raw-alloc.json.

• Benchmarks show no statistically significant regression in performance, despite the shift to safe abstractions.
• Binary size is 1kb smaller than the current release build on my machine and 20kb smaller than the download.
• All existing tests pass. No regressions were found during local testing.

[Barca545]

@microsoft-github-policy-service agree

[Barca545]

The only relevant changes for my PR are in gap_buffer and virtual_memory. I accidentally uploaded more files than I intended. My apologies. I will fix the commits later today.

I created a VirtualMemory type that exposes bounds checked methods for reading and writing to the allocation. If this is a good approach there are some ergonomic tweaks I can make to improve the final implementation.

[lhecker]

I'll close this PR for now. I'm not sure if this is an area worth changing at the moment. I apologize if this is disappointing.