Fix migration with fkeys

Creation of fkeys doesn't work in sqlite, so we should do these
changes in another dialects.
Fix bug 1204823.

Also we can have a problem with data conflicted with declared ForeignKey.
We should dump "bad" data to another place, upgrade and create FK.
Downgrade method should restore dumped data.

Change-Id: I33089d6f47dcde4cf716a3d303c8df23dd19cd07
Add a specialized Event Type model and db table

As the events API gets fleshed out and more robust,
it will become increasingly necessary to ensure that the
database schema modeling events has the ability to quickly
retrieve a list of event types. With the current schema
having a foreign key from event to unique_name (the
monolithic generic string key lookup table), in order to
get a simple list of event types, one needs to do the following:

SELECT DISTINCT e.unique_name FROM event;

Not only is this inefficient, but the readability of the
model and database schema suffers from the generalization of
the unique name field relationship. With this patch, a new
event_type table is added to the schema to allow for quick
and easy lookups of event types like so:

SELECT id, desc FROM event_type;

This will lead to future ability to categorize
event types with ease. Instead of adding columns to the
monolithic unique_name table, we would only need to add a foreign
key relationship to the new event_type table tying the event_type
to a future event_type_class table...

This patch also renames "event_name" to "event_type" everywhere
to avoid confusion.

Change-Id: I6e630ec534f16ba1bb9370d1859ae7640fc6b05b
Partial-Bug: 1211015
Merge "Fix migration with fkeys"
Merge "Add a specialized Event Type model and db table"