Backport object size/sibling limits to 1.4

* Objects larger than warn_object_size will log a warning on read or
  write. The default is 5MiB
* Objects larger than max_object_size will fail to be written, logging
  an error message. By default no limit.
* Objects with a sibling count larger than warn_siblings will log a
  warning on write. By default 25.
* Objects with a sibling count larger than max_siblings will fail to
  write, logging an error message. By default no limit.
Clarifying put fail messages for max size/siblings

Making the sibling error/warnings a bit different. It used to be the
same with different severify.
Now both write failure messages have the same prefix
Return error in overloaded reqid

This is the same trick that overload uses to return an error code to the
put FSM. Because the FSM expects this from overload, a non-overload
error ends up returning the request id as the error reason, which sucks.
With this change, a local put will return a too large or too many
siblings error to the client.
Local puts will likely fail in this scenario. Now, it's possible for the
local put to succeed and remotes to fail (due to different thresholds or
divergent values with different number of siblings). In that case the
error reason might talk about failure to satisfy pw or related.  We
currently don't have a system for prioritizing different vnode error
responses. Except for overload, which eagerly returns overload if any
vnode returned an overload code.
Make handoff warn but not drop large objects

The code was restructured a bit to avoid losing data during a handoff if
the object has too many siblings or is too large.
So direct puts will fail if too many siblings or are too large, but if
an object is moved by handoff somewhere, it will just generate a
warning.
Jon made me do it.
Merge pull request #836 from basho/feature/large-object-warning

Backport object size/sibling limits to 1.4