Add retrieve details

[indomitableSwan]

This PR closes #12.

Things it doesn't address, but came up as questions during drafting:

• User identifiers (see #52). We are using user_id for both OPAQUE and our application, but these identifiers should be different. For OPAQUE, the user identifier should be human-memorable account information, whereas the latter is a 128-bit UUID. The likely solution here is that the key server should generate and store this ID during registration (#11), and pass it back to the client during authentication (#10).
• How the user knows its key identifiers. This may relate to #48, or we could implement functionality that retrieves a list of the user's associated data

[marsella]

Second bullet is a good point. In phase 0, we included a "get all key IDs" function that didn't make it into this version yet. Would "a list of the user's associated data" include anything other than key IDs?

[indomitableSwan]

Second bullet is a good point. In phase 0, we included a "get all key IDs" function that didn't make it into this version yet. Would "a list of the user's associated data" include anything other than key IDs?

See #53

[indomitableSwan]

There should probably be implementation guidance around the handlings of master_key added in...