feat: implement local DidPublisher

[paullatzelsperger]

What this PR changes/adds

This PR adds a local DidPublisher, that is intended for testing and demo purposes to provide a working out-of-the-box experience.

The LocalDidPublisher "publishes" DID documents by simply modifying their DidState and setting it to PUBLISHED. Then, there is the
DidWebController, which serves DID documents by taking the request URL and converting it to a DID. For example if the controller's context is configured as

web.http.did.port=10100
web.http.did.path="/"

then the DidWebController would accept all paths starting with "/". That means, that DID documents with the following IDs would be returned, provided they are found in the database:

http://localhost:10100/did/someone/say/cookie                      --> did:web:localhost%3A10100:did:someone:say:cookie
http://localhost:10100/did/someone/say/cookie/.well-known/did.json --> did:web:localhost%3A10100:did:someone:say:cookie
http://localhost:10100/.well-known/did.json                        --> did:web:localhost%3A10100
http://loclahost:10100/                                            --> did:web:localhost%3A10100

Note that the port of the host gets URL-encoded.

The LocalDidPublisher only works with did:web DIDs.

Why it does that

out-of-the-box experience for IATP

Further notes, questions

• the IDs of the documents that are stored in the DB will depend on the URL of the endpoint, which may make it necessary to dynamically generate DID documents. This could be cumbersome, especially in clustered environments. so maybe we could make the DidWebParser extensible, to intercept the URL->DID conversion?
• similarly, an endpoint may be reachable via multiple URLs, e.g. Kubernetes: pod IPs, Service addresses, ingresses, LBs,... Being able to define aliases could be beneficial there too.

Linked Issue(s)

Closes #189

Please be sure to take a look at the contributing guidelines and our etiquette for pull requests.