feat: realign service with DID Core spec

[dbluhm]

This PR realigns the service endpoint definitions to what is outlined in the DID Core spec. Specifically, permitting the service endpoint to be a string, map, or set of strings and/or maps. DIDs, DID URLs, general URLs, and now any string is now permitted. This is to support specifying arbitrary URIs. The rules for parsing URIs would be overly complicated to fully validate; slightly greater flexibility is preferrable to maintaining large regexes.

Through this realignment, pydid will now support didcomm:transport/queue as a serviceEndpoint value.

[TheTechmage]

My one concern about opening it up for more flexibility is that it would possibly allow values that would be considered invalid endpoints. On the flip side, should things change in the future spec wise, or someone has a use-case that requires something new during a POC that isn't currently in-spec, having the underlying framework be more permissive would be much nicer.

And besides, if developers want to shoot themselves in the foot, that's on them and they already have plenty of tools at their disposal to do so. Community wise, I'm certain that we'll discourage out-of-spec uses and encourage developers to design to-spec, else they risk incompatibility with the rest of the ecosystem. 🤔

All things considered... I'm not opposed to these changes. LGTM

[dbluhm]

My one concern about opening it up for more flexibility is that it would possibly allow values that would be considered invalid endpoints.

Yeah, indeed. You raise good points and counterpoints. I arrived at more or less the same conclusion. Even if we did have more comprehensive URI validation, the variety of URIs mean that you could end up with something that's valid according to the spec but still unusable to the application anyways. My mentality with these changes is that we'll parse it into useful objects like DID and DIDUrl if we can but otherwise we'll let the application determine the validity of the endpoint.

I'll also call out that while the base Service object is now more permissive, the DIDCommService objects are still narrower, in accordance with the DIDComm V2 specification and relevant Aries RFCs. This will again help us to parse useful values according to the DIDComm specs but leave the validity of the final endpoint/uri to the application.

Thanks for the review!