start a generic event log in the db

[chadwhitacre]

I looked into using triggers or rules for this, but we want to include the participant_id of the actor for each event, and we don't have that info at the db layer, only at the application layer. Therefore I propose to refactor our db access layer to make this possible. I plan to use hstore to hold information about each event so that it's easily extensible.

[chadwhitacre]

The model we have with the tips table where we only ever INSERT, we never UPDATE--that's great in that it keeps historical information around and is fast to write, but it makes read queries cumbersome. Let's start using this generic event log for some things (I'm currently working on adding a suspended column to participants as part of #350), and then compare the two approaches when we're further down the road.

[chadwhitacre]

Hmmm ... hstore values can only be strings (right?). Perhaps a generic solution won't work. It seems like we don't want to cast everything to a string here.

[chadwhitacre]

Pruning.