[Task] Implement all `controller` features from the DID Spec

[JelleMillenaar]

Description

Add all controller features to the framework as they are mentioned in the DID specification. This includes the DID Document controller field and the controller fields inside of verification methods / relationships.

Motivation

Allows the creation of identities that are managed by other identities.

Resources

Link to any resources relevant for the task such as Issues, PRs, reference implementations, or specifications.

• DID Controller field
• DID Controller inside verification methods
• DID Controller discussions

Change checklist

Add an x to the boxes that are relevant to your changes, and delete any items that are not.

• [ ] The feature or fix is implemented in Rust and across all bindings whereas possible.
• [ ] The feature or fix has sufficient testing coverage
• [ ] All tests and examples build and run locally as expected
• [ ] Every piece of code has been document according to the documentation guidelines.
• [ ] If conceptual documentation (mdbook) and examples highlighting the feature exist, they are properly updated.
• [ ] If the feature is not currently documented, a documentation task Issue has been opened to address this.

### Tasks
- [ ] https://github.com/iotaledger/identity.rs/issues/1315
- [ ] Allow arbitrary Identifiers as controllers
- [ ] Research how to deal with circular DID Controllers (a controls b, b control a).
- [ ] Consider controlled verification methods
- [ ] Consider controller updates/authentication

[cycraig]

There are several obstacles to implementing controllers right now due to having to resolve the entire history of a DID. Primarily, verifying signatures on both integration chain and diff chain updates from controllers require resolving the controller DID document (for every controller in its history); if the referenced verification method was changed or removed, the signature verification will fail. To solve this we would need to pin signatures to a specific version/hash of a DID document.

This was partially addressed in #458 by allowing verification methods from controllers to be embedded in the controlled DID document directly, and allowing the verification method controller property to be set which references the controlling DID without needing to resolve it.

[cycraig]

This issue is still on hold due to technical limitations with the current DID method.

The planned UTXO DID Method atop Stardust will see controllers handled at the protocol level rather than the client, since nodes will validate whether or not an address is allowed to update an Alias Output.