Replace `bearer_did`+`key_selector` as the mechanism for signing with a `Sign` type

Currently, in a number of places we follow a pattern such as:

```rust
pub fn sign(
&self,
bearer_did: &BearerDid,
key_selector: &KeySelector,
) -> Result {
```

...for the the calling code to indicate what keys to sign with. Instead, we should replace this `bearer_did`+`key_selector` input parameter pattern with a generalized `Sign` function type.

The `bearer_did`+`key_selector` idea is conceptualized as: "_here is my bearer DID, which includes a reference to my key manager, and here's the key I want to use to sign, now you handle the actual signing_."

This is beneficial in that it places DID's as first-class citizens in out developer experience, but it's also constricting in that we only enable cryptographic signing through the existence of a bearer DID. A guiding principal we embrace in the rust initiative is to _prefer modularity over convenience_. This is an instance where we have convenience but we need modularity. We will have use cases where we need to support cryptographic signing without the existence of a bearer DID.

It'll likely make the most sense to place this `Sign` function in the `crypto` package.

We need to ensure this won't cause our bindings initiative to increase in complexity by an order of magnitude. First things first is to prove how such a paradigm shift would be implemented with UniFFI bindings. UniFFI UDL supports a feature known as [callback interfaces](https://mozilla.github.io/uniffi-rs/udl/callback_interfaces.html), but it appears they may not be considered to be "soft deprecated."

> These are described in both UDL and proc-macros as an explicit "callback interface". They are (soft) deprecated, remain now for backwards compatibility, but probably should be avoided.

In which case, perhaps there is a different implementation solution for passing function types as function parameters.