Update to dispatch 0.11.0

The version 0.10 used previously seems to suffer from some resource
release problems. Updating to 0.11 should help solving problem #15.
Delete database only if present
Better check for database existence

Issuing a HEAD request to the database name returns some data about the
database, or issues a 404 if the database does not exist
[imp #18] Switch http backend to spray

This rewriting was motivated by some scalability problems encountered
with the previous Http library. Relying on spray adds a new dependency
to akka, which may seem quite a heavy dependency, however, akka is a
well tested and widely used piece of software that scales really well.
It also allow us to fine tune requests, especially streaming requests.
To make it short, I am convinced that it is worth adding such a
dependency for all the benefits it brings to us.

This also introduces some changes in the asynchronous API which become
much cleaner, removing the need to deal with annoying `Either` objects.

The implementation was also cleaned up to adapt to the new underlying
Http library, which allowed me to write things in a better way.

As this change introduces a lot of new stuffs and involves heavy
rewriting of the library, I decided to make it a major version, bumping
it directly to 1.0.0 (switching to semantic versioning at the same
time).

closes #18
Merge pull request #19 from gnieh/wip-spray

Switch Http backend to spray
[imp #20] Implement change stream as Observable

Using rxjava-scala, we are able to provide a high-level, nice-to-use API
for being notified about changes in the database. By combining the power
of akka actors and `Observables` such streams can be combined and worked
with in any fashion the user wants it.

closes #20
Merge pull request #21 from gnieh/wip-observable

[imp #20] Implement change stream as Observable
Remove previsouly depracated entities
Choose view types on query

Currently, one has to choose the types of the key, values and documents
upon view creation. This is not well suited for CouchDB, especially for
value types, which may change whether we reduce the view result or not.
By making this choice only on view query, we can have more fine-grained
control over the expected types.
Ideally, it would be even better if, e.g. a query with `include_docs`
set to `false` wouldn't require the user to provide the `Doc` type.

This is the first step toward issue #14.
Add first try for a low-level view API