LibAFL does not poison over-allocated memory for an input

**IMPORTANT**
1. You have verified that the issue to be present in the current `main` branch

**Yes**

**Describe the bug**

LibAFL uses `Vec` as a backing structure for `BytesInput` which will over-allocate memory when inserting/appending bytes, and will not deallocate memory when removing bytes. LibAFL does not poison the delta between the vector's `len()` and `capacity()`, which may reduce ASAN's effectiveness in detecting small out-of-bounds reads since memory between the vector's `len()` and `capacity()` offsets are considered addressable.

**Expected behavior**

LibAFL should call into ASAN to poison the delta bytes, or provide an API to get the number of delta bytes, when handing off the `BytesInput` to the harness.

If this does not work, LibAFL should *try* to guarantee the minimum number of bytes are allocated by calling `input.bytes_mut().reserve_exact()` when inserting bytes.

**Additional context**

I noted this issue when I was evaluating using LibAFL as a backend for a LibFuzzer replacement [I'm working on](https://github.com/landaire/fazi). I tried to see if LibAFL provides non-mutable access to the backing vector that would work in the harness callback to do this myself and couldn't find a way to do so. I then looked to see if LibAFL takes this into account on its own, and it appears as though it may be a gap in the current implementation.

The way I approach this problem is very similar to libFuzzer/honggfuzz's approach. I [weak link](https://github.com/landaire/fazi/blob/685dae50e495fb932d875cba8461807c9fc84e0a/src/weak_imports.rs#L12-L38) the `__{m,a}san_{un}poison_memory_region` functions, and [poison/unpoison the appropriate memory range](https://github.com/landaire/fazi/blob/685dae50e495fb932d875cba8461807c9fc84e0a/src/exports.rs#L271-L305) at the start and end of the fuzzing loop (respectively).