Implement a DID Document builder and convenience functions about ssi HOT 3 CLOSED

@clehner this could be a good next step along towards the ultimate goal of satisfying the test suite. Recommend reviewing some prior art:
https://github.com/digitalbazaar/vc-js

from ssi.

@wyc Should there be another constructor that takes all the options to add to the new struct? Getter/setter functions? Creating a document from deserializing a JSON string? What would be convenience functions?

from ssi.

@clehner I think we should have an "easy to get going" workflow but more advanced options at the user's choice. Would like to avoid having to set 50 different options to get a DID Document to work with, a simple did:key DID Document should be simple to spawn and work with.

Some interesting code patterns and discussions thereof to consider:
https://github.com/colin-kiegel/rust-derive-builder
rust-unofficial/patterns#64
https://github.com/rust-unofficial/patterns/blob/master/patterns/builder.md
https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis

Especially curious about the functional options pattern and if it would fit.

Perhaps we can further consider the resources linked here, which describe DID URL Referencing, one of the most common things we expect to do with DIDs:

w3c/did-core#364
w3c/did-core#253 (closed due to inactivity, but still relevant)
https://w3c-ccg.github.io/did-resolution/

Imagine someone building a Universal Resolver (https://github.com/decentralized-identity/universal-resolver) with our library (we may do this, actually). Imagine someone taking the output of the Universal Resolver as per the DID Resolution spec using our library to feed into their application software which must inspect the DID Document.

As per serialization, we should consider a JSON-LD + CBOR-LD representations, keeping our core data models abstract and agnostic to wire formats as much as is reasonable.

from ssi.