bulk save of leaf trees in RevTreeBuilder
Overhead of ForwardingStagingDatabase.put checking for existence in repodb is too high, don't do that
Optimize time and space of tree writing

By using a buffer envelope for speed and memory efficiency
and encode empty envelopes as a single Double.NaN
BDB JE ObjectDatabase performance improvements.

Make the staging database non transactional.
Use a single writer thread for bulk operations.
Change BulkOpListener to receive an ObjectId instead of RevObject
so the db is freed from having to keep the actual object in memory
just for the sake of notifying the listeners.
Let EnvironmentBuilder use the je.properties config file fully
instead of setting properties by hand.
Simplify transaction processing, getting rid of the transaction per thread
utilities we were using.
Encode on the calling thread, write on the writer thread.
DeepMove (and hence CommitOp) performance improvements.

Copy and delete in one shot, using a separate thread to delete
objects from the origin database as they were copied to the target db.
ImportOp performance improvements.

Make WorkingTree use several threads to fetch paged data
from the FeatureSource and perform the import quickly, as long
as the origin data source supports paging.

Make WorkingTree use RevTreeBuilder2 which writes Nodes to temporary
index files as features are inserted, and builds the actual RevTree
as a post step in a sorted way so RevTreeBuilder creates almost no
dangling trees.
Huge performance optimization in computing the perscribed storage order of tree nodes.

NOTE this commit breaks backwards compatibility with pre 0.6 repositories as nodes
are stored in a different order inside trees.

Use a FNV-1 <http://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function> hash function
instead of SHA-1 to compute the storage order and bucket by depth of tree nodes.
The FNV hash function has a very good distribution for strings, not too much collisions,
and is really fast to compute out of strings. So much that we used to need some kind
of buffer in NodePathStorageOrder when using SHA1 which also lead to heap memory issues,
but we don't need it anymore with FNV.

Yet I have tested it with up to 50 million nodes with no resulting colissions, and is orders
of magnitude faster than SHA-1 when using the Guava SHA-1 HashFunction (e.g. bellow 4s instead of over 100s
to sort 5M nodes).
Make WorkingTree.insert always use the optimized code path and simplify ImportOp
mark temporary node index files to be deleted on JVM shutdown
Use nanoTime for GeogitCLI's console progress listener
faster feature building function for OSMMapOp
refactor osm file download to a separate method and make sure the executor service is shut down
Use a buffered input stream when parsing ths .pbf and make sure the stream is closed at the end
Download osm file from the calling thread.

Get rid of the ExecutorService to download the osm data, its
using one single thread anyways, so simplify the code.
make osm import use a single WorkingTree.insert call for the whole dataset
Use a point cache backed by a temporary database for osm import
change contract of ObjectDatabase.putAll to also notify the BulkOpListener of feature blobs not inserted cause they already exist
use an ExecutorService for BDBJE object db sync tasks
final clean up for OsmImport performance improvements
Make osm download import directly from the http stream.

Opens the overpass api stream and imports directly from it.
If --keep-files is specified, the file is written down to
disk at the same time the import takes place, no need to
first download the whole data and then import from it.