Async crypto: support interrupt-driven response delivery in addition to polling

[AlexLanzano]

PR #337 introduces the async crypto API (*Request() / *Response() split) and documents the client polling pattern:

  ret = wh_Client_Sha256UpdateRequest(ctx, sha, in, len, &sent);
  if (sent) {
      do {
          ret = wh_Client_Sha256UpdateResponse(ctx, sha);
      } while (ret == WH_ERROR_NOTREADY);
  }

Polling is the only delivery mechanism today. For embedded targets where the transport signals response arrival via an interrupt
(inter-core doorbell, MBOX IRQ, DMA-done IRQ, etc.), the client is forced to either busy-poll or schedule a polling task, both of which
waste cycles and latency.

Proposal

Allow the application to register a per-context (or per-operation) callback that the comm/client layer invokes when a response is ready
for consumption. The typical flow:

1. Transport IRQ fires → platform glue calls a wolfHSM-provided "response ready" entry point.
2. wolfHSM calls the user-registered callback (or schedules deferred work) passing enough context to identify which pending operation
   the response belongs to.
3. User callback invokes the matching *Response() function to drain the response and complete the operation.