Implement Clone for crypto frontend types

[bugadani]

These frontend types can be freely created, and they contain the partial result of their respective operation. They can be big, but there is no underlying reason to prevent cloning them, e.g. to branch off calculation after some common prefix has been processed.

ESP32 is again a special case, because we can't save SHA state on it. This means we can't clone a frontend that started operation using hardware, and that means we can't clone SHA context at all - conditionally failing would be a worse solution than just removing hardware acceleration altogether.

Closes #4707

[Copilot]

Pull request overview

This PR implements the Clone trait for crypto frontend types (RsaContext, AesContext, and Sha<X>Context), allowing users to branch off calculations after processing a common prefix. ESP32 is excluded from SHA cloning because it cannot save/restore SHA hardware state.

• Added Clone implementations for work queue infrastructure (WorkItem, WorkQueueFrontend)
• Made crypto contexts cloneable: RsaContext, AesContext, and SHA contexts (except on ESP32)
• Added test for SHA clone functionality

Reviewed changes

Copilot reviewed 5 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
hil-test/src/bin/ecc_rsa_sha.rs	Adds test verifying that cloned SHA contexts maintain independent state
esp-hal/src/work_queue.rs	Implements Clone for WorkItem (manually) and WorkQueueFrontend (derived), resetting state for cloned items
esp-hal/src/sha.rs	Conditionally derives Clone for SHA-related types, excluding ESP32 due to hardware limitations
esp-hal/src/rsa/mod.rs	Derives Clone for RSA work item and context types
esp-hal/src/aes/mod.rs	Implements Clone for AES operation (manually calling Key::copy()) and derives for AesContext
esp-hal/CHANGELOG.md	Documents the new Clone implementations

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.