Can KeyMaterial be Vec-based? #82

If we are standardizing on always assuming a memory allocator, then we can consider making KeyMaterial carry a Vec<u8> instead of a [u8; KEY_LEN], which would reduce a number of friction points across the library.

pub struct KeyMaterial<const KEY_LEN: usize> {
    buf: Secret<[u8; KEY_LEN]>,
    key_len: Secret<usize>,
    key_type: KeyType,
    security_strength: SecurityStrength,
    allow_hazardous_operations: bool,
}

The core change would be pretty simple: keep the <const KEY_LEN: usize>, but change it to <const INITIAL_CAP: usize> so that the type aliases for KeyMaterial128, KeyMaterial256, KeyMaterial512 are still there, and efficient about not needing to up-allocate for the common cases.
Then change buf: Secret<[u8; KEY_LEN]> to buf: Secret<Vec<u8>> or possibly buf: Vec<Secret<u8>>.

This will require some thought about Secret since currently it can only handle statically-sized types due to how the zeroizer is implemented. Possibly buf: Vec<Secret<u8>> is the right answer and does not require any changes to Secret.