Why should Client be so different than Chainable?

Chainable and Client interfaces were almost the same and their
differences seem purely accidental. Having the same interface
everywhere seem easier and will allow client injection later.
Remove helper methods from the Client itself (SRP)

The Client class already handles Net::HTTP bridging and most of
the semantics of the options. It makes sense to frees it from also
having to provide http helpers, which are available through Chainable.

Removing the helper methods does not hurt (provided Client is part of
the private API?). Client#request become *the method* for which injection
will take place later.
Clean handling of options in Chainable#request.
Regroup secret about :response option.

The :response option handling is already spread between Chainable
and Client. It seems it makes sense to avoid unnecessary secret
spreading.

By the way, a Response object is also returned on HEAD requests made
through Chainable#request directly.
Client injection through Chainable#default_client
Show that chainable is not chainable at all.
Options in Client#initialize and include Chainable.
Introduce an Options helper class.

The Options class encapsulates the management of options. For now,
it implements the following ones: :response, :form, :headers,
:before, :after.
Follow the :callbacks specification strictly.
Options behaves like a Hash.

No Hash-like write-support is added so far, but it could be later.
Options.new coerces to an Options instance.
Ensure behavior of Options#[] on unknown key.
Implement Options merging.

The merge operator takes care of merging :callbacks and :headers
in a POLS way. For now, :form is not merged as a Hash and the value
at right is always used.
Let Client use the Options class.
Use default_options to avoid name clash with HTTP verb
Properly add the :response => :auto case.

Previously Chainable implemented a different heuristics than Client
for :response. Chainable used :object on HEAD and :parsed_body on
other verbs. Client always used :object.

This commit removes this difference and introduces :auto as option
value. It is the default one, it is implemented in Client directly
and it corresponds to the Chainable behavior above. This means that
{:response => :object} is necessary on Client to get its previous
behavior (broken private API, therefore).

By the way, we could restore the previous behavior simply by setting
:object as default in Options and forcing something else through
default_options in Chainable and/or Http. It seemed simpler to get the
auto behavior immediately in Client, though.
Implement chainability through pure Client branching.

This commit fixes the chainable behavior. It works by simply
instantiating a Client instance and branching on default options.

Chainable#default_headers and default_callbacks will be restored
in a future patch. default_client has been removed, as monkey
patching branch allows achieving the same goal as Client injection
before.
Remove Parameters and EventCallback and restore defaults.

Parameters and EventCallback are no longer used. This commit also
restore the default_headers and default_callbacks accessors. The
presence of the writers is much arguable IMHO.
Delegate argument robustness to Options.
Make Options friendly with exception bracktraces.