feat: proper resolutions APIs for AssetDIDs

[ntn-x2]

Fixes https://github.com/KILTprotocol/ticket/issues/2093.

Improves the API around AssetDID resolution, mirroring what we already do for KILT DIDs.

Specifically:

• Rename the DidResolver, DidDocumentExporter and DidDocument modules of the types package by prefixing them with Kilt. Nothing will break for users.
• Rename the AssetDid.parse() function to AssetDid.resolve()
• Add AssetDid.resolveCompliant(), which mirrors what we do for KILT DIDs
• Include AssetDid.exportToDidDocument(), which also mirrors what we do for KILT DIDs

Unit tests for resolver and exporter have also been included.

[ntn-x2]

@rflechtner I guess because of the parse -> resolve renaming, this could not be included in a patch release for the SDK, so we have to wait for the next release (Eth linking) to eventually include this and build the universal resolver driver.

[ntn-x2]

@rflechtner I see your point. Indeed the AssetDID spec v1 was designed since the beginning to be a simple wrapper around CAIP identifiers. The goal would be for it to evolve in v2 to include credentials as part of the resolution process, perhaps, and more, for instance alsoKnownAs for bridged assets and so on.

I acknowledge at this point what we have might not be much, and my idea for a "better" interface was indeed to set things up for improvements in the resolution protocol at a later time.

Is asset DID "resolution" a feature that we need to properly release soon or can we live with the parsing functionality that we released in 0.31.0 for a while?

We can definitely go ahead with the parsing functionality. The point is, we call them DIDs, and I would expect people to have a resolve function to resolve the DID, not a parse one. In this sense, you can also then call light DID resolution parse since it's entirely self-contained, but we call it resolve because it's still fetching/parsing/producing information starting from and identifier.

I'm also asking because this is a huge amount of code for something that still has the feature set of a single regex-expression. I could see that if we fail to develop a vision for what asset DIDs bring to the table beyond what CAIP identifiers can do, we may fall back to just issuing credentials to CAIP-19 ids instead. But once it's out it's out.

Yes, but I think having the identifier as a DID allows us to build on top of a standard. If we fall back to using CAIP identifiers, we can definitely never ever build anything on top of that, since there is no standard we can build on. I am open to perhaps update the AssetDID standard to include information you think is missing, but from day 1 we kind of agreed this is the "bare minimum" DID spec for assets, and that we would build on top of that once we have time and if we see fit.

More to the details of the implementation here, is there a reason we need to have both a pseudo-DID document AND an actual DID document for asset DID resolution? They are virtually identical, no? Wouldn't it be enough to only resolve to actual did documents to make the api surface more manageable?

It was mainly to keep the user experience similar to what we have for KILT DIDs. Objects the SDK can more easily understand, and something that can be exported (mainly used by the resolver, in the future). Again, right now this might not make a lot of sense because of what we have, but I would see the two DIDs to evolve together in the SDK. Maybe that's an wrong assumption/vision on my side? I also see public credentials and normal credentials evolving together, since for me they are conceptually very similar.