Destroying a persistent key open through multiple handles does not invalidate other handles

### Description

Consider the following sequence of operations (assume nothing fails):
```
psa_set_key_id(attributes, 3);
psa_open_key(attributes, &handle1);
psa_open_key(attributes, &handle2);
psa_destroy_key(handle1);
…
psa_xxx_setup(…, handle2, …); // Using a destroyed key!
…
psa_set_key_id(attributes, 3);
psa_generate_key(attributes, &handle3);
…
psa_destroy_key(handle2); // Destroying a different key!
```

Initially, there is a key with the identifier 3, and we take two handles to the same key. The first call to `psa_destroy_key` wipes the key slot for `handle1` and wipes the key in storage, but does not invalidate the key slot for `handle2`. This results in several undesirable behaviors.

1. If the key is transparent (i.e. not in a secure element), it is still possible to use the key via `handle2`, because Mbed Crypto maintains an independent copy of the key in each slot. This means that `psa_destroy_key` failed to deliver its promise of wiping the key material, making the key unusable.
2. If the key is in a secure element, it is still possible to attempt to use the key via `handle2`. But the key has been wiped from the secure element, so attempting to use it will either fail or trigger an operation with some other key (which may even be of a different type, leading to interesting cryptographic information leaks) depending on whether the slot number in the secure element has been reused.
3. If the key identifier is reused before calling `psa_destroy_key` on `handle2`, this destroys a key in storage which is not the key that `handle2` references.

This is somewhat related to #86 which is about multipart operations retaining key material of a destroyed key.

### Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

Start by tracing the psa_open_key and psa_destroy_key entry points and the handle-lifetime logic they use. Reproduce the two-handle sequence from the issue, then verify that destroying one handle invalidates every other handle and cannot affect a newly reused key identifier.

Written by the indexing model from the issue text.