implemented reverse iteration

The c++ source was used as a reference for a working implementation, though adjustments were made to fit the java nuances. Unit tests have been changed and added to properly assess the iteration behavior (forgive me, but some are in junit and some in testng), and the benchmark application has also been adjusted to track reverse iteration. In the implementation itself, there are a few caveats that you might want to be aware of:

1) Your comments made it clear that performance was a fairly high priority. I did my best to optimize where I could, but forward iteration has slowed 10-15% according to the included benchmarking application. Further optimization could be possible to bring it closer to the previous performance levels. Reverse iteration is also much less performant than forward iteration (when compared to the delta between the c++ forward/reverse benchmarks). There is more room for improvement here as we did not rigorously pursue performance for reverse iteration.

2) There were some inconsistent behaviors in the JNI version -- and possibly the c++ LevelDB -- that don't make much sense. For example, next() and prev() can be mixed freely while mid-iteration, but upon reaching the end of the listing next() becomes invalid (correctly) but prev() also becomes invalid. I fixed this behavior to be more intuitive and inline with other java iterators like ListIterator, which can be traversed up and down completely. Unfortunately, this would break compatibility with applications that depend on this behavior in the JNI version. If drop-in compatibility is more important than consistent behavior, you may wish to change this.
Another such behavior quirk is in seeking for a key not found in the db. If the sought key is smaller than any key in the db, an iterator is returned starting at the first item (sensible). Likewise, a non-present key sought in the middle of the keys will return an iterator positioned at the next largest key (also sensible). Seeking for an item larger than any of the keys, however, will return a completely invalid iterator -- hasNext() and hasPrev() are both false. The intuitive behavior in my view is to return an iterator positioned at the end of the db, so the closest smaller item is returned by prev(). This is the behavior I implemented, though again for compatibility purposes, you may wish to change this.