Restructure `dids` package

[mistermoe]

Overview

@mihai-chiorean and I chatted and figured out how to restructure the dids package 4 hipster vibes (a.k.a subjectively simpler API surface) and to set us up for some upcoming features

this should be the last chonker PR in this repo as the updated structure hopefully sets us up for the long haul.

[!IMPORTANT] most of the changes in this repo are moving files around and adjusting method names to accommodate new package names

[!WARNING] dids/resolver.go will be refactored / cleaned up in a subsequent PR but the API surface will remain the same. Currently it feels kinda weird in the sense that the file is a bit hard to read and quickly figure out what's going on

Notable Changes

Each did method is now self contained in it's own package, so did creation now looks like:

didjwk.Create()

instead of

dids.NewDIDJWK()
dids.NewDIDDHT()

---

BearerDID now has access to the DID's Document. This is necessary for did:web

---

types representing data models defined in the did core spec now live in didcore

---

types used for different representations of DIDs e.g. DID (the string), BearerDID (did + key manager), PortableDID (literally portable representation of a DID, keys, and metadata) now live in the did package

---

added READMEs to each directory with usage examples. check out README for dids pkg

---

New Directory Structure

dids
├── README.md
├── did
│   ├── bearerdid.go
│   ├── bearerdid_test.go
│   ├── did.go
│   └── did_test.go
├── didcore
│   ├── document.go
│   ├── document_test.go
│   └── resolution.go
├── diddht
│   ├── diddht.go
│   └── diddht_test.go
├── didjwk
│   ├── didjwk.go
│   └── didjwk_test.go
└── resolver.go

package	description
did	contains representations of a DID.
didcore	contains all of the data models defined in the DID Core Spec
did<method>	one package for each did method
dids	high-level APIs that support multiple DID methods

Rationale

The primary goals for the api surface for is:

• self-contain each did method in its own package in order to provide an api surface that looks like didjwk.Create(), diddht.Create etc.
• provide a Resolve method capable of resolving all did methods in this module without any configuration or registration

The directory/package structure is a result of achieving both goals in a way that hopefully makes logical sense and prevents cyclic imports.

Internal Dependency Diagram: