move more control of copy transfers to vnode and add basic forwarding

* Instead of vnode manager triggering each transfer for each source
  index it triggers one "copy" transfer each. The
  copy transfer contains the list of target indexes to "copy"
  to. The vnode then triggers an outbound ownership_copy one at a time
  until all transfers for the list of indexes are complete. Once
  complete, it notifies the vnode manager like reglular handoff.
* Added (barely tested) support for forwarding.
* This approach more closely resembles typical ownership
  transfer/hinted handoff for a vnode. The primary differences are: 1)
  data is not deleted after handoff completes  (this needs to be
  addressed -- at some point some data needs to be deleted, see
  comments). 2) in the case that an index exists in both old & new
  rings it may copy its data to target indexes and then keep
  running. In this case data also needs to be deleted (also punted on)
  but some data must still remain (referred to as rehash in Core 2.0
  doc). 3) the same vnodes that are affected by #2 also differ in that
  after they begin forwarding they may stop and continue running in
  their regular state. In addition, when forwarding, these indexes will
  forward some requests but others will still be handled by the local vnode
  (not forwarded). What to do with a request during explicit forwarding
  (when vnode returns {forward, X} during handle_handoff_command) when
  forwarding that message would result in it being delivered to same
  vnode still needs to be addressed (see comments).
* This commit adds a vnode callback, request_hash, required only if
  supporting changing ring sizes. We probably need something better than
  this but its sufficient for a prototype. The function's argument is
  the request to be handled by the vnode and the return value is the
  hashed value of the key from the request. This is necessary because
  the request is opaque to riak_core_vnode. One obvious issue, for
  example, is in the case of FOLD_REQ there is no key to hash -- even
  though we probably shouldn't be and in some cases don't forward this
  anyways.