Fix computation of block number bounds (off-by-one)

The block numbers could be off by one due to incorrect rounding.

m_geom* now contain the minimum and maximum block numbers that
should be in the map.
Set initial y limits to INT_MIN/INT_MAX (instead of -/+30000)
Fix SEGV after failing to open output file: throw runtime error

The result of opening the file was not checked, resulting in a
NULL pointer dereference if it failed.
Add option '--verbose', and make it report requested and actual map coordinates.
Fix vertical limits handling

Node and map-block coordinates were mixed up, causing the min/max
vertical coordinate limitation to be broken.

The confusion was removed, and --min-y and --max-y now work as they
should.
Add option --forcegeometry to force using the requested geometry

Instead of reducing the map size to the minimum necessary for the
size of the world, a map of the requested size is always generated.
Report world coordinate limits and map heigth and depth limits with --verbose
Report number of 16x16x16 blocks in world and map as well, with --verbose
Fix memory leak (and performance) re-preparing sqlite3 statement over and over - once is enough
Optimize database access - load only blocks that are needed
Add new options to README, and include some extra example cmake commands
Database performance tweaks

Added the option to bulk load and cache entire world rows at
a time when using sqlite. Caching is implemented in the
database class this time around.
Enabled using --sqlite-cacheworldrow on the command line.

This is essentially re-introduces the database access strategy
that was used originally, but as an option.

Currently, one block is read at a time from the database.
The original behavior was to read and cache one entire world
row at a time, irrespective of whether or not only a (small)
subsection of the world was being mapped.
Under some circumstances, in particular if the entire world is
mapped or a relatively large percentage of it (blocks-wise), the
bulk loading and caching may outperform the one-by-one strategy,
even though it usually loads many more blocks than are actually
needed.

It seems that leveldb won't benefit from any kind of caching or
bulk loading of blocks, so none was implemented.

Leveldb does compile now. Still not tested on a database :-(

Improved the database statistics (printed with --verbose).