Fix remaining memory issues during the last 0.5% of processing planet.osm with the dense memory cache

[patrickbr]

This is an unfinished draft PR to fix the remaining memory issues in the final 0.5% of phase 2 (dump) when processing planet.osm with the dense RAM cache.

The current version attempts to further reduce the memory and disk space overhead of calculating the geospatial relations.

libspatialjoin requires string IDs to identify geometries. Previously, the full prefixed IRI (e.g. osmnode:3454354544) was used as an ID. With 492069c, we use the more efficient schema

[type][integer ID]

where [type] is a single byte identifier (1 for nodes, 2 for ways, 3 for way areas, 4 for relation area, and 5 for relations), and [integer id] is the OSM ID encoded as a variable-length integer. These bytes are directly stored in a std::string used as the ID for spatialjoin. spatialjoin never interprets these IDs, so they can contain arbitrary byte sequences. In particular, note that libspatialjoin stores them as std::strings, not C strings, so 0 bytes are allowed and will be returned from the cache correctly (otherwise, IDs like 128 would not work).

This has the following benefits:

1. the ID size of a typical OSM ID goes down from around 18 bytes to around 5 bytes
2. the disk space required for the geometry cache (where these IDs are stored in) is reduced, especially for nodes (where ONLY the id is stored on disk)
3. the memory overhead of the relation tracking (via libspatialjoins "collection of geometry refs" functionality) is greatly reduced.

For a further reduction of the memory footprint in the final 0.5%, I am waiting for profiling results from massif.