Refactor database

This is quite a fat refactoring. I extracted the common functionality from `catalog::Database` and created an templated base class `sqlite::Database<>` that uses [CRTP](http://www.wikiwand.com/en/Curiously_recurring_template_pattern) to allow for static polymorphism of the implementing concrete Database classes. The idea is, that each *database* in CernVM-FS inherits from `sqlite::Database<>`.

I've done that already for `catalog::Database` (which is now called `catalog::CatalogDatabase`) and `history::Database` (now: `history::HistoryDatabase`). *Note that the namespaces are becoming more and more clumsy.* We should investigate if also the cache database could benefit from `sqlite::Database<>`, but I am quite sure it can.

The `sqlite::Database<>` class now provides:

* Interface to create new databases (`sqlite::Database::Create()`) and open existing ones (`sqlite::Database::Open()`)
* Allow for on-the-fly schema revision upgrades by the concrete implementations
* `GetFreePageRatio()` as a measure for database fragmentation
* Consequently: `Vacuum()` to compact fragmented databases
* Concrete implementations can have domain specific compaction (i.e. needed for the `CatalogDatabase` that can also defragment it's *rowids*)
* Central handling of the *properties* table
* Common methods to open and commit SQLite transactions

Both, the `CatalogDatabase` and the `HistoryDatabase` classes are rather slim (less than 50 lines for the history) and only add domain specific things.

Furthermore this pull request contains an extension of the `sqlite::Sql` class, to allow binding and retrieving data fields based on template specialisation. I needed it mainly for the *properties* handling in `sqlite::Database<>`, but it also allows for more readable code here and there.

Finally there is a (hopefully) exhausting unit test set for the new `sqlite::Database<>` class.
Just curious, did the IsBusy case ever occur?