Potential Unsoundness in `StableVec` via public `addr`, `cap`, and `len` fields

**Description:**

Hello! Thanks for your repo, which helps me a lot. Recently, I've identified a potential soundness issue in the `stable-layout` crate.

The `StableVec` struct exposes its internal state fields (`addr`, `cap`, and `len`) as **`pub`**. However, the crate also provides a safe `Drop` implementation for `StableVec` that reconstructs a `Vec` from these raw parts to deallocate memory:

```rust
// From src/stable_vec.rs
impl Drop for StableVec {
fn drop(&mut self) {
let _vec = unsafe {
Vec::from_raw_parts(
self.addr as usize as *mut T,
self.len as usize,
self.cap as usize,
)
};
}
}

```

Because these fields are public, entirely safe Rust code can mutate them to arbitrary values. When the `StableVec` instance is dropped, it will attempt to free an unowned or invalid pointer with incorrect layout information, leading to immediate Undefined Behavior (UB), such as double-free, invalid-pointer-free, or segmentation faults.

**Proof of Concept:**

The following strictly safe code triggers a memory corruption crash during `Drop`:

```rust
use solana_stable_layout::stable_vec::StableVec;

fn main() {
// 1. Create a valid StableVec
let mut stable_vec = StableVec::from(vec![1u64, 2, 3]);

// 2. Maliciously corrupt internal state via safe public fields
stable_vec.addr = 0x12345678 as u64; // Arbitrary address
stable_vec.cap = 999999; // Arbitrary capacity
stable_vec.len = 999999; // Arbitrary length

// 3. Drop occurs here, triggering unsafe Vec::from_raw_parts with corrupted data.
// This results in a crash (e.g., free(): invalid pointer).
}

```

Can the visibility of `addr`, `cap`, and `len` fields be changed from `pub` to private? Since the crate already provides safe getter methods like `as_vaddr()` and `len()`, users can still access the information without being able to break the struct's safety invariants.

Thank you for your attention to this issue!