Lock gemspec to faraday ~>0.7

Fixes yield discrepancy between 0.7 and 0.8, reported by #46.
Lock capistrano to ~> 2.0 in gemspec
Release 1.9.3
Ensure falsey values are sent in context. #43
Fix bug with duplicate Faraday adapter

Recently, we were building our Faraday connection using 0.8 syntax:

Faraday.new(:request => request_options, :proxy => proxy_options) do |conn|
  conn.adapter Faraday.default_adapter
  conn.headers['X-API-Key'] = api_key.to_s
  # ...
end

This failed in older versions of Faraday because 0.8 changed the object yielded by `Faraday.new`. Prior to 0.8, `Faraday.new` yielded a `Faraday::Builder` instance (which doesn't have `#headers`):

https://github.com/lostisland/faraday/blob/d7c23bc2e8ad3a309a96f4d09a0fb26fd9c524bc/lib/faraday/connection.rb#L38

In 0.8 `Faraday.new` was changed to yield the Faraday::Connection object itself:

https://github.com/lostisland/faraday/commit/9830fdb137f1a522ddd6632af77000f871f9625d

Semantic versioning fail? We fixed the issue by tapping into the connection object rather than passing a block to `Faraday.new`. This would ensure we're always acting on a `Faraday::Connection`:

Faraday.new(:request => request_options, :proxy => proxy_options).tap do |conn|
  conn.adapter Faraday.default_adapter
  conn.headers['X-API-Key'] = api_key.to_s
  # ...
end

This worked fine, so we released it. Then we noticed a strange byproduct: the gem was posting an additional payload to our API after each request. Our collector API responds with an ID as JSON after successfully capturing a notice: `{"id":"123"}`. The second request body posted was this JSON response from the first.

After some digging, I realized that because we were no longer passing a block to `Faraday.new`, it was first initializing the `Faraday::Builder` with default handlers:

https://github.com/lostisland/faraday/blob/5f3703220be76a8391364d278a1dba40e9751729/lib/faraday/builder.rb#L53

Calling `conn.adapter Faraday.default_adapter` on the connection afterwards was forwarding `#adapter` to `#builder`, which resulted in a second `Faraday::Adapter::NetHttp` handler being added to the builder. This naturally results in Faraday posting the response body from a first request as a second request to the same endpoint every time a request is made...... :)
Release 1.9.4
Lock guard at ~>1.8.3 (for 1.8.7 support)
Just run the specs without appraisals.
Fix hash syntax
Bring back the UserInformer. Closes #17
Added Regexp param filtering.
Updated CHANGELOG and README.
Merge pull request #50 from oneamtu/master-regexp-param-filtering

Added Regexp param filtering.
Allow API key to be overridden by notice.
Return nil from Sender#api_key_ok?
Add some tests to the sender for overwriting the api key.
Update changelog next release version. (minor release)
Filter query strings. #40
Make sure uri is required. #40
Fix changelog rebase mixup