Pluck charge id from error response on Stripe
CHANGELOG
Merge pull request #1251 from Shopify/stripe_failed_response_id

Populate authorization in failed responses from Stripe
Quickpay: Fix passing acquirers field

The original implementation of protocol v7 called this field "acquirer"
(without the "s"), which matched old and incorrect documentation
provided in the past by Quickpay. 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.

The correct documentation can now be found on the Quickpay website:
http://doc.quickpay.net/api/messagetypes.html#index1h2
http://doc.quickpay.net/api/messagetypes.html#index2h2

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 use
`acquirers`.

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 asked Quickpay to update all of their v7 documentation to
reflect the correct field name.  At this time it appears they have
done so.

Closes #1246.
Quickpay v7: Pass an amount when storing cards

Closes #1189.
Quickpay: Expand list of supported countries

Also fixes the homepage url and display name.
Validate CreditCard verification value

Closes #1236.
Authorize.Net CIM: Fix updating a payment profile

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`.
Wirecard: Add optional CommerceType element

Closes #1253.
iATS: Update country list

Added Brazil.  Removed Japan and New Zealand.

Closes #1254.
Add Borgun gateway

https://www.borgun.is/

Closes #1232.
NAB Transact: Allow timeout customization

Allow a custom request timeout.  NAB Transact support has said:

"... the time out value set in the API message simply determines how long we
will wait before returning a timeout response to you, the transaction
still remains in flight and can still be processed even after this
occurs."

We default to 60 seconds but we now allow other values to be specified.

Closes #1255.
Wirecard: Add store/purchase/authorize by ref

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.

Closes #1243.
Worldpay: Add support for Switch cards

Many Maestro cards in the UK, for example those prefixed with 6789, are
recognised by AM as Switch. This commit adds support for these, using
the Maestro WorldPay code.

Closes #1208.
FirstData e4: Send correct card type

Closes #1252.