Improve DID URL dereferencing for verification methods

[clehner]

Copied from #122

Verification method maps may appear in a DID document in multiple places, e.g. authentication or assertionMethod. Previously we required them to be under the verificationMethod property. When a verification method (or its id) is included in one of these arrays, it indicates a verification relationship between the DID subject and the verification method. These verification relationships correspond to the proofPurpose property in linked data proofs. DID Core says that the assertionMethod verification relationship is used for issuing Verifiable Credentials. It also says that authentication is used for authenticating via challenge-response protocols. Typically, the authentication proof purpose is used for creating Verifiable Presentations, as seen in VC Data Model - Example 45, and in test cases in vc-http-api-test-server such as case-1.json. We should respect verification relationships when verifying proofs.

This PR sets the default behavior for verifying a verifiable credential or verifiable presentation to require the proof's verification method to be in the DID document with the verification relationship corresponding to the proof purpose in the verification options - with assertionMethod the default proof purpose for a VC, and authentication the default for a VP.

This change only affects verification. During issuance, the proof purpose and verification method must still be passed in as options.

The publicKey is added back to the DID document even though it is no longer in DID Core, since there is a test case in vc-http-api-test-server that depends on it. It is treated as another place where verification methods may be stored, like the verificationMethod array. A verification method in the verificationMethod array or publicKey array should also be referenced in one of the verification relationship arrays like assertionMethod and/or authentication, to express a verification relationship and therefore be used with linked data proofs.

[sbihel]

I assumed there were no particular change from the previous PR I reviewed.