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.
Use authorization instead of authorization_check for Amex on store

Amex does not support authorization_check, so an authorization is done
instead.
Auth.net: Mask card number if length == 4 when building credit card XML

In order to use the same card number when updating a payment profile (a
"partial update"), you must send the last-four digits of the card as the
CreditCard#number, masked (e.g. `XXXX11234`).

This change checks if the card number being passed into
`add_credit_card` is 4 digits. If it is, we assume a partial update is
being attempted, and we mask this value in the way Auth.Net expects.

See http://www.authorize.net/support/CIM_XML_guide.pdf, page 70, under
`cardNumber`.
Updates FirstData e4 gateway to send correct card types