Allow updating a book

BrainzStem has now been extended to have the versioning system I've been planned
added. The new Branch and Revision types have been added, and the schema has
slightly changed to have parenting for revisions. BookBrainz.Model.Book has been
extended with some primitives for working with versions, revisions and branches,
and insert/update functions now operate using these primitives.

Currently, the system doesn't yet take advantage of the full potential of the
system, but I've kept it simple to simply update the master branch of
entities. This does provide a coherent history however, so at least so far we
have correct data.
Abstract the versioning over to BrainzStem

This adds the 'insert' and 'update' functions to the 'CoreEntity' type
class. These have default implementations, but do require the 'addVersion'
function to be implemented. This is currently doing a bit more than it needs to
(it manages the revision as well), and can be stripped down a little more.

Currently, only Book has addVersion defined.
Include rev_id when fetching core entities via views
Make sure to update a branch with the *new* revision

It was previously using the old one, so the changes were never visible to the
user.
Add a very simplistic interface to editing books

This uses the previous update functions to simply add a new version and update
the master branch. This is all I plan for the first public version, but we still
need to log the user who commited this revision before we can go public.
Fixes to run under the latest Snap
Introduce entity tables and GID tables

This schema refactoring introduces entity tables, and entity GID redirection
tables. This has come from noticing a couple of things:

1. That we need a way to fetch all commits for an entity, regardless of its GID
2. That entities may have multiple GIDs (after merges) and we need to be able
   to respond to all GIDs
3. That some entities may need to refer to another entity, generally, rather
   than a specific commit. For example, an edition has a book, but it doesn't
   care what commit it's at. Likewise, author roles link to a person, but not
   a specific version of a person.
Make use of the new entity level references

This schema change makes a few changes to cross-referencing entities.

* book_person_role now references a general person, and a specific book
  commit. This means that a commit can change the person that a role refers to.
* edition_person_role now references a general person, and a specific edition
  commit. Same reason as above.
* edition_revisions now generally references a publisher. This allows the
  publisher to change over specific revisions.
* edition generally refers to a book. This means that over all, an edition
  refers to a book.

A few things to note. The book reference from edition means that an edition
cannot be moved via a commit. This will probably change, which leads on to the
next point...

I don't think commit is the right place to keep track of cross referencing
data. In Git, this would be a tree object, and I think we might need to
introduce tree objects soon here too (yet another abstraction...). In this
model, a book tree would contain the book version and book_person_roles. Edition
tree's would contain a publisher reference, an edition version and
edition_person_roles.
Introduce _tree tables

The _tree tables provide a way to link various bits of data into a single
cohesive entity. In the case of a book, this is the version and book-person
roles. In the case of an edition, it's the book the edition belongs to, the
publisher who published it, the version of the edition itself, and all
edition-person roles.

In 94f8f238af2472635a8865e499bfbbc40e9cff3d I mentioned that I wasn't happy
storing these links in the commit object, so this simply expands on that line of
thought introducing the tree objects.
Add primary keys for tables that don't have it

The _role tables don't seem to have primary keys, and the author_credit table
doesn't need to exist so that's being dropped.
Add the editor table, and link it into revisions

I've introduced the 'BookBrainz' editor for now for those revisions that don't
have an editor associated with them (though I guess nikki would have been the
correct editor to create!).
Introduce 'Concept'
Loaded core entities should point to their tree, not their version
Rethink the model API

I was unhappy with the definition of the BrainzStem.Model type clases, and have
redesigned them. We now have a nice set of building blocks that work with the
versioning system, and some generic abstractions that build on top of them. That
lets us have a single definition for 'create', 'update', and friends. The
essential buliding blocks that vary from type to type are defined in the
CoreEntity type class.

As most CoreEntity's at the moment have an identical implementation, I've
introduced the GenericVersioning type class, which provides an instance with the
minimal amount of boiler plate. This is now one bit of code I'm still unhappy
with, because it requires UndecidableInstances. This hasn't been a problem yet,
but I bet it could be in the future. Luckily, any problems will be at compile
time I believe, so we'll certainly know when we hit them.
House keeping

Fix hlint suggestions and most warnings from -Wall
Introduce the BBID table and s/gid/BBID/g

This commit aims to fix 2 issues. The first is that we (in #bookbrainz-devel)
think that identifiers should be unique to the context of the entire BookBrainz
application, not just a single concept. This commit moves in that direction, by
having a single list of identifiers. Note that this is *not* enough to enforce
the invariant we're looking for, but for all purposes it does the job now. It
will still allow you to have a book and an edition with the same ID in the
schema, but due to the way creating new concepts works now (always asking for a
new identifier), this probably won't happen in practice.

The second change in this commit is to stop refering to things as 'gid's and use
the more type agnostic term BBID. Kuno/warp mentioned that there's no real need
for GIDs here, and he has a point; BookBrainz is the only source capable of
creating generating IDs and can guarantee their uniqueness, so UUIDs aren't
entirely necessary. It might be possible to use something more human-friendly. I
don't know if we *will* make this change, but the possibility is a bit more
there now.
Changes to work with latest Elasticsearch bindings

Search now takes an offset (which I'm defaulting to 0), and document keys are
Text, not String.
Fix the new GenericVersion stuff to specialise on VersionConfig
Chase the latest Snap 0.6 API
Move a few things around

All the data type definitions are now in the same file. I don't see much benefit
of having each one in its own file (I guess I'm too used to needing that in
other projects!). I've moved a few of the conversion instances out of the type
declarations too. I want to make all of this as independent of storage as
possible, mostly.