Proper prefix and hashed_key fields

[florimondmanca]

Is your feature request related to a problem? Please describe.
As of 1.3, the ID of an API key is a concatenation of the prefix and hashed_key. These are available as properties on the model. We are willing to move to an integer ID in the future (see #41), but storing the prefix and hashed_key in their own fields is a necessary first step.

Describe the solution you'd like

• Add prefix and hashed_key fields to AbstractAPIKey (they must be non-editable, and the prefix field must be unique).
• Keep the ID as it is today, i.e. a concatenation of prefix and hashed_key.
• Add a migration guide, addressing in particular users who may already be using AbstractAPIKey.

Describe alternatives you've considered
Keep things as they are, i.e. do the migration of prefix, hashed_key and idall in 2.0: this introduces much bigger changes and upgrade barriers. Populating the prefix and hashed_key introduces no breaking changes at all.

Additional context
/