Improvements to password salt record

[corrideat]

Problem

Working on the password change PR gave me two ideas. Currently, there are two minor issues with password salt storage:

1. The salt record is indexed by username and not by contract ID. I don't think this is even an issue, but I think it might make more sense to index the record by contract ID. The plan all along was using contract IDs, but the challenge is that we need to set this before the contract ID is known.
2. The salt record is set before the identity OP_CONTRACT event is stored. We 'need' to do this, but it's not ideal because we'd like the salt record to be set atomically with creation of the identity contract. Setting the salt first is safer than sending the event first, lest we create a contract that can never be used.

With the password change PR (#2446), I introduced atomic updates, so we could use the same mechanism to fix 2 above. Furthermore, if we do it atomically, we could also solve 1, meaning that the salt record can be indexed by contract ID (instead of by username).

However, fixing 1 (changing the index) means that the server DB will need to be updated, or else it won't be possible to log in to existing accounts. It will not mean that contracts need to be recreated, rather a one-time migration job on the SQLite DB would do.

Solution

1. Implement atomic registration of password salts, using a token, similarly to what Password changes #2446 does for password updates.
2. Implement indexing by contract ID instead of by username. (This would happen in POST /event upon redeeming the token).
3. Update the frontend code (mostly in app/identity.js) to work with these changes.
4. Write an update script to migrate existing password records (from username to contract ID).

[corrideat]

If we do this before https://github.com/okTurtles/group-income/milestone/3, then we don't need to write an update script.