Make storage interface more friendly

[nsatragno]

The storage interface should more easily allow developers to integrate this library with their existing user models, especially for relational databases.

• The documentation should include the fields that are expected to be stored and their types.
• search should probably be removed since it's not being used.
• We should be careful that the design makes sense after Feature request: Allowing more than one authenticator #12 is implemented (e.g. we might want to be able to delete individual credentials).

It could also be a good idea to change the attribute user.authenticator to user.webauthnCredential since not all authenticators are webauthn authenticators and in theory the same user could have multiple credentials on the same authenticator, but this is a little bikesheddy :)

Blocked on #12

[EternalDeiwos]

Agreed for the first two points -- on the last, I'd say that individual credentials can be deleted by just setting a new object that omits that credential in particular. Anything wrong with that approach?

@nsatragno @inorganik what do you think about adding a new storage interface (and documentation) for the user session as well? That would also give greater control on that front (CC #15)

[nsatragno]

individual credentials can be deleted by just setting a new object that omits that credential in particular. Anything wrong with that approach?

Hmmm, I think on a relational database that would require SELECTing the user, diffing against the user authenticators, and figuring out what to delete. I just realized that's the same thing for adding authenticators though 🤔.

Maybe that's acceptable for an MVP, and we should consider having two kinds of adapters, one for relational and one for document databases.

@nsatragno @inorganik what do you think about adding a new storage interface (and documentation) for the user session as well?

+1