Driver instance should support multiple "verification suites" (or key types)

[dlongley]

Ideally, verification suites would be renamed to key types -- and a driver instance could support N-many of these. Otherwise N-many driver instances must be created and mapped and managed externally.

This is particularly true for using get() -- where systems may want a driver that can resolve multiple different did:key types. The driver should support detecting the multikey header used and use the appropriate key type to import and generate the DID document.

[dlongley]

It looks like #47 makes some changes here -- but it doesn't seem like they are in the right direction, requiring the caller to pass in what type of key is expected in a different way, instead of requiring the caller to say / configure the driver with what types of keys are allowed, such that when get() is called the driver can auto-determine whether the input matches one of the allowed key types.

It's fine for the caller to still specify the key format they would like for a given key type, but they will not know what the key type is and shouldn't have to pre-parse the DID to figure that out.

[dlongley]

Addressed by #55.