Balanced: Handle legacy card tokens

Closes #1241.
Braintree Blue: Default verification merchant id

If the merchant has configured the merchant_account_id and they want to
use the verify_card option, they probably want that verification run
against their configured merchant account, since Braintree Blue allows
for multiple merchant accounts. This sets a smart default for
verification_merchant_account_id, while still allowing it to be set
independently.

Closes #1244.
Braintree Blue: Kill expected to fail remote tests

They were really testing Braintree internal validations, which are out
of scope for the AM tests.
Extract integrations into an offsite_payments gem

A shim is used to allow existing consumers of integrations to
(hopefully) see no issues.

Closes #1239.
Remove defunct Samurai gateway
Drop stated/tested compatibility with Rails < 3.2

Until we can unhitch ourselves from Rails train completely, we will
track the severe security Rails maintenance policy (background:
http://weblog.rubyonrails.org/2013/2/24/maintenance-policy-for-ruby-on-rails/).

Technically we're not in compliance with that yet since we do not
support/test against Rails 4.1, but that will come soon.
Fix .travis.yml to refer to correct Gemfile
Remove no longer needed test dependencies
Wirecard gateway: Add card store and purchase/authorize by reference

Wirecard supports the notion of "Recurring Transactions" by allowing
the merchant to provide a reference to an earlier transaction
(the GuWID) rather than a credit card.  A reusable reference (GuWID)
can be obtained by sending a purchase or authorization transaction
with the element "RECURRING_TRANSACTION/Type" set to "Initial".
Subsequent transactions can then use the GuWID in place of a credit
card by setting "RECURRING_TRANSACTION/Type" to "Repeated".

This implementation of card store utilizes a Wirecard "Authorization
Check" (a Preauthorization that is automatically reversed).
It defaults to a check amount of "100" (i.e. $1.00) but this can be
overriden.  In order to reuse the stored reference, the
+authorization+ from the response should be saved by application
code.

Already present was the ability to run a purchase transaction using
a GuWID.  This commit adds the ability to do the same for an
authorization transaction.

Note: any transaction can generate a reusable GuWID reference by
setting the option :recurring to "Initial".  This functionality
already existed but is now documented.
eWAY Rapid 3.1 gateway

Thanks to @moklett who had a major part in helping me put this together.

We don't want to require billing_address for #purchase because it
doesn't require one itself in the API.

Added tests to remote for purchases / etc with and without billing
address.

During all of this we also discovered that #store requires a billing
address with at LEAST country and name. From the eWAY folks this is for
legacy API reasons.
Adding #store and #update support for the Elavon gateway
Quickpay v7 has an "acquirers" field in requests

The original implementation of protocol v7 called this field "acquirer"
(without the "s"), which matches some of the current Quickpay
documentation but contradicts other parts.  We learned via Quickpay
support (through debug of a chargify.com merchant issue) that the field
in the request is called "acquirers", representing a list of acquirers
to attempt, ordered by preference (i.e. `acquirers=nets,teller`).  The
response will contain a field called "acquirer" which conveys which
acquirer was actually used in the transaction.

Before this change, attempting to set the old `:acquirer` option would
result in an MD5check hash mismatch, since the ActiveMerchant code would
use the `acquirer` field in the calculation, but Quickpay would not.

After this change, both ActiveMerchant and Quickpay agree on the
MD5check hash when the `:acquirers` option is set, and the `:acquirers`
option has the intended effect of setting the preferred acquirers for
the transaction. (The latter can be negative-tested by setting the
value for acquirers to an invalid acquirer value and observing the
error response: "Error in field: acquirers")

Despite the change to the option key (`acquirer` to `acquirers`), I feel
this is a safe, backwards compatible change since attempting to set the
old option could never result in a successful transaction - the MD5check
hash mismatch error would always occur.

Note: I have asked Quickpay that they update all of their v7
documentation to reflect the correct field name.  At this time I am
still waiting for those changes to happen.
Quickpay: Adds currency for v7 store operations

While working with Quickpay in production mode, it was discovered that
"amount" and "currency" are required values for store (subscribe)
operations in the v7 API.  Without it, subscribe operations complain
with "Error in request parameters". This is confirmed by their
documentation, which currently states that both "amount" and
"currency" are required:

http://doc.quickpay.net/api/messagetypes.html#index2h2

This commit makes the change such that only the subscribe parameters for
v7 (and up) are changed.  New unit tests were added to prove the correct
parameters are now being sent, and all existing remote tests were run
and are passing.