Add #riak_core_fold_req_v2 record, part 1 of 2

Move definition of ?FOLD_REQ to v2.

Add functions to riak_core_util.erl to create v2 versions of the
record: arity 1 (upgrade #riak_core_fold_req_v1 record to the v2
record), arity 2 (args = the two record elements of the v1 record)
and arity 4 (args = the four record elements of the v2 record).

Disable request forwarding in riak_core_vnode:forward_or_vnode_command()
if the request explicitly contains not-forwardable annotation.
Cluster Metadata: The Basics

This commit implements the basic moving parts for riak_core's new k/v
store for cluster-wide information. Cluster Metadata is meant to
replace current uses for metadata stored in `riak_core_ring`.

The interface for interacting with the store is defined in
`riak_core_metadata`. Data is read and written locally and is fully
replicated to all nodes eventually. Data is stored on disk using dets
and is managed by `riak_core_metadata_manager` (the ground work has
also been laid to keep a copy of data in-memory w/ ets for use on
reads). Data is addressed by a given prefix (a two-tuple of any erlang
terms) and a key. Each stored prefix/key has an associated logical
clock (a dvvset -- more below). The representation of the object and
its clock are abstracted via `riak_core_metadata_object`.
`riak_core_broadcast` implements a new broadcast/gossip protocol for
disseminating updates to other nodes. The module is implemented to be
a general broadcast protocol that could be used by other
subsystems. `riak_core_broadcast_handler` is a new behaviour that
defines the API a module must implement to use
`riak_core_broadcast`. `riak_core_metadata_manager` implements this
behaviour. `riak_core_broadcast` is based off the plumtree protocol
(http://www.gsd.inesc-id.pt/~jleitao/pdf/srds07-leitao.pdf) with some
modifications to make it more partition tolerant and fit with
riak_core's membership model. The implementation uses the sender-based
tree approach mentioned but not analyzed in the paper. The current
implementation does not fully guaruntee at-least once delivery (it
will be fully implemented in a future commit).

`riak_core_broadcast` and `riak_core_metadata_manager` run per node
and are started after the ring manager.

This commit introduces dvvset.erl from
https://github.com/ricardobcl/riak_core/blob/dvvset/src/dvvset.erl. This
may not be the actual version of Dynamic Version Vectors
used. `riak_core_metadata_object` is meant to abstract the object
representation and logical clock so a switch to a new implementation
of dvvset or one just using vector clocks can be made easily.
Improve Cluster Metadata Storage

* move to using a dets file per prefix/subprefix
* store data in ets table per prefix/subprefix. read from ets
* restricts prefix/subprefix to binaries
Basic Iterators for Cluster Metadata

Allows iteration and folding over all keys stored under a
prefix/subprefix
Further Cluster Metadata Storage Improvements

* MD5 prefixes for use in filenames. Raw binaries are unsafe and
  difficult to parse.
* Store metadata in in a manifest file. Folding over files in a directory
  to determine existing data is unsafe, error prone, and stupid.
* Re-allow prefixes to contain atoms. To prevent collision between binaries
  and atoms a filename trailer is appended.
* Sync all dets writes to disk so we don't easily lose data on emulator crash"".
Fix Cluster Metadata Conflict Resolution

* pass proper arity function to dvvset:reconcile/2
* timestamp resolved value
Add Optional Conflict Resolution to Metadata Iterators

* When resolution is used, iterators are "single-use".
The iterator functions aren't pure in this case. If no resolution option
is provided then this resriction does not apply
* Resolution can be done via function or lww like get/3
Allow Conflict Resolution on Metadata Write

extend riak_core_metadata_object:modify/4 to take a
resolution function (it differs from resolve/2, see edoc).
Add Conflict Resolution in Metadata Folds

using the existing support in iterators
Add Logical Deletion to Cluster Metadata

* similar to ring metadata
* write tombstone values on delete
* handle tombstones on read
* resolvers and modifiers must be tombstone-aware. see typespecs.
* iterators/folds can optionally return the tombstone value or can provide
a default value to return or function to apply when they are encountered
Iterate only a Subset of Cluster Metadata Keys

If keys are tuples then a match-spec like pattern
can be passed as an option to iterator/2 and fold/4 to
filter which keys the iterator visits.
Teach riak_core Bucket Types

Like buckets, we must teach core this because a few subsystems
use them. Bucket Types provide a method for grouping buckets
logically (see https://github.com/basho/riak/issues/362).
Support both new and old-style crypto MD5 functions.
Update rebar.config for new branching model
Update protobuffs, webmachine, folsom tags
Update webmachine dependency tag
Isolate app.config from non-default bucket type properties, implement reset

Non-default bucket-types are unaffected by changes to app.config and
bucket types can have their properties reset to the hardcoded defaults.
Add riak_core_capability handling for fold requests
Merge branch 'jrw-cluster-meta' into eas-bucket-type-merged
Merge branch 'adt-bucket-type-defaults-and-reset' into eas-bucket-type-merged