Various minor AAE changes prompted by Riak 1.3 QA

This pull-request contains three changes to AAE based on on-going 1.3 release testing and LevelDB changes.

First, this pull-request makes calls between KV vnodes and `riak_kv_index_hashtree` synchronous, using calls rather than casts. This provides backpressure to the vnode if the hashtree writes cannot occur fast enough. Technically, this shouldn't happen. It happened during tests because LevelDB was unfairly throttling AAE writes, preventing AAE from making progress. This has since been changed. However, we want to play it safe and add backpressure anyway. Of course, this backpressure just shifts the problem. If hashtree writes can't happen fast enough, then we will have unbounded message queue growth somewhere. Without this pull-request, the growth would occur in a `riak_kv_index_hashtree` process, with this patch the growth occurs in a `riak_kv_vnode` process. However, because of the new KV health check code in Riak 1.3, Jon/I decided that having potential message queue growth in the KV vnode is preferred. If this scenario happens, the health check will notice, kick in, and disable the KV service on the node.

NOTE: It is intentional that I use 'catch' when generating the now synchronous calls. This is because the previous use of cast was assumed in the design, and there are scenarios where the `riak_kv_index_hashtree` process may be dead when a message is sent. For a cast, the message would be dropped. For a call, it will generate an exception. We catch the exception as to not crash the KV vnode. Easier to do this rather than re-writing/re-validating all of AAE to guarantee never passing in a potentially dead PID. Future plans for 1.4 already include a completely different approach to backpressure, so this is largely a temporary change/situation anyway. 

Second, this pull-request adds code to ensure that all hashtree iterators are closed before attempting to close the LevelDB instance backing a group of hashtrees. This change was originally necessary as new LevelDB code changed semantics requiring iterators to be closed before a database could be closed/cleaned up. Very recent LevelDB changes have once again returned to the original semantics (closing a database handle will close/cleanup iterators automatically), but Jon/I/Matthew decided that committing this code anyway can't hurt and is a good "just in case".

Third, this pull-request updates how `hashtree.erl` calls `eleveldb:iterator_move` to account for how LevelDB now generates error messages. In the past, passing in an already closed iterator would generate an error tuple, now it generates a `badarg` exception. The change to hashtree ensure that these exceptions are caught and ignored as desired, as hashtree was already coded with the assumption that `iterator_move` may be called on already closed iterators in some scenarios.