Fix GeoIP database magic marker/type parsing

The GeoIP database has a magic marker of 0xFFFFFF, followed by one byte
indicating the database type (country/city, IPv4/IPv6). This sequence
can appear at the end or nearly at the end, followed by some other
garbage.

The code is supposed to start at the end, then move up one byte at a
time until it finds the magic, then move forward three bytes (magic
length) to read the type.

The current code moved backwards 4 bytes at a time, which isn't not
according to the de facto spec (libGeoIP). Presumably, this happened
because of an oversight while inspecting MaxMind's code: libGeoIP does
"lseek(fno, -3, SEEK_END);" followed by a "read(fno, delim, 3);"
eventually followed by a "lseek(fno, -4l, SEEK_CUR);". My guess is that
the reverse engineering missed the fact that read() actually seeks
forward, and hence reading 3 bytes and seeking -4 actually seeks -1 from
the original position.

Note that the databases as shipped by MaxMind contain exactly 3 bytes
after the database type, which just happened to make the current buggy
code work(!). Debian actually recreates the binary databases from the
"source" (CSV) with a home-made converter program which places the
magic/type being at the end of the file, something which is valid and
accepted by libGeoIP.

This addresses issue #28.
Merge pull request #28 from paravoid/issues/28

Segfault while reading GeoIPv6.dat