Support Encrypted Credit Card Fields End to End (Braintree)

NOTE: This PR requires the following change in spree/spree_gateway to work 100% and store unencrypted mm/yyyy from Braintree when using their JS library.

https://github.com/spree/spree_gateway/pull/125

Braintree encourages users to encrypt credit card data on top of HTTPS. They will then just decrypt the values on their side.

This poses a problem for Spree for month and year because there are several validations that they are integers and the date is in the future. It also poses a problem on credit card number with the current regex replacement. This change will allow us to support encryption by the gateway if it is assigned as source attributes in the payment. The validations are now conditional on cc mm/yyyy. cc_number is just assigned. This will allow validations to pass but still allow the encrypted values to be passed through to Braintree where they can process and decrypt.

https://github.com/spree/spree/blob/master/core/app/models/spree/payment.rb#L113-L118

When the data is returned from Braintree unencrypted, it should be saved and validated as usual.

Braintree reference:

https://www.braintreepayments.com/docs/javascript/encryption/overview
https://www.braintreepayments.com/docs/javascript/encryption/usage

do not store encrypted values in db

The encrypted values created by Braintree JS are quite long and exceed the 255 varchar limit in spree_credit_cards.

Rather than increase the size and impose a migration on people, let's simply blank the values out before save, and restore them after_save.

The actual decrypted values will be provided by Braintree auth response and that is when the right values will be saved (see changes to spree/spree_gateway).