Rewrite OpenSSL Engine from scratch

The current `ossl_engine` is broken and cannot be build. It depends on `mcr_api_resilient` (which does not exist in our code base) and uses API types that have been refactored into `azihsm_api`.

I'd like to propose rewriting the engine from scratch and adding the code back in piece-by-piece where we can. I'm thinking of the following structure:

- `openssl-sys-engine` - Raw FFI bindings via bindgen against the OpenSSL 1.1.x headers
- `openssl-engine` - Generic rust abstractions over the ENGINE API: wrapper, error queue integration, typed `ex_data`
- `engine` - That's the actual `azihsm_engine`

As a first step I'd like to bring in the bare minimum skeleton to run `openssl engine -t` in order to loads the skeleton. No interaction what so ever. Then I'd like to add in the following pieces one at a time:

1. Key Loading - The engine itself does not support OSSL_STORE or anything like that. However I'd like to stick to the URI we defined for the provider. We need to bring this into the `ossl_engine`.
2. EC keygen / sign
3. RSA (Sign, Decrypt)
4. ECDH
5. AES ciphers
6. Digests & HMAC
7. HKDF
8. Engine Controls i.e. Key import, delete, attest command
9. Resiliency

Not all commands can be fully tested with the CLI - so we will need a mixture of CLI and API tests (again). I also like to pick up what we already did in the old engine code. We have to look into what can be brought over and what not.

Also I'd like to discuss a design decision here:
- Method duplication: Do we want/need that also public key operations go through the library? In theory we could only overwrite private key operations i.e. sign and keep the verify in OpenSSL. We can export the pubkey so no communication is needed anymore with the azihsm. However if we want to keep everything

Start by examining the existing `ossl_engine` and the refactored `azihsm_api`, then define the proposed `openssl-sys-engine`, `openssl-engine`, and `engine` boundaries. Run `openssl engine -t` against the minimum skeleton; done means the skeleton loads successfully without implementing cryptographic operations. Later work would require separate CLI and API tests for the listed features.

Written by the indexing model from the issue text.