Eating elephant, first step (events, db schema)

As discussed at #1549 we need to pick a place where the elephant is softest and start there. Tracking `claimed_time` and `username` appears to be **it**.

The `events` table is our log. The ultimate goal being that any db state at any point of time in the past should be reconstructable. After several tries at this it seems prudent to keep two participant ids in this table. The first one is to be used "the participant" (tipper, claimer etc.). The second one is to be used as "the other" (tippee, team etc.). This setting allows somewhat sane filtering. Using ids instead of usernames makes the past unmutable which is what we need for any log.

The next steps are to fold goal, number, statement, bitcoin and other attributes into this architecture.

The more chewy parts of the elephant include user creation semantics, tipping and absorbing (take_over).

The ultimate test will be reconstructing the current state of the db just from the `events` table.

Please review & merge.