[Extensions] Introduce more informative enum for Extension results

Nobody has claimed this yet.

From my reading of the spec, the result of client extension processing on either get() or create() could be:
1. **Accept** - Use the *client extension input* as *client extension output*. This is used for authenticator extensions that require no processing on the client, eg. [12.3. Large Blob Key (largeBlobKey): Client extension input / output / processing](https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-client-to-authenticator-protocol-v2.2-rd-20230321.html#sctn-largeBlobKey-extension).
2. **Accept & update** - The client re-writes the authenticator extension input, with different fields, e.g. [12.5 HMAC Secret Extension (hmac-secret): Client extension processing](https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-client-to-authenticator-protocol-v2.2-rd-20230321.html#sctn-hmac-secret-extension).
4. **Drop** - Remove this extension's payload altogether from the authenticator request, e.g. [12.1. Credential Protection (credProtect): Client extension processing](https://fidoalliance.org/specs/fido-v2.2-rd-20230321/fido-client-to-authenticator-protocol-v2.2-rd-20230321.html#credBlobFeatureDetection) drops the create() payload if credBlob size is unexpected.

```rust
enum ClientExtensionProcessingResult {
Accept(cbor::Map),
Drop,
}
```

_Originally posted by @AlfioEmanueleFresta in https://github.com/linux-credentials/libwebauthn/issues/77#issuecomment-2674105649_

Locate the client extension processing paths for get() and create(), then compare their current result handling with the WebAuthn extension-processing sections linked in the issue. Define how the result represents accepting input unchanged, accepting updated output, and dropping the payload; done means both paths use the more informative result consistently.

Written by the indexing model from the issue text.