WIP - Payment Tokens, Apple Pay Payment Tokens, Authorize.Net accepting tokens

### 1. Payment Tokens
Here we revisit https://github.com/Shopify/active_merchant/pull/1433. After some discussion around https://github.com/Shopify/active_merchant/pull/1436, I think we have a decent abstraction here, since: 
 - We know that if we're processing a payment token in lieu of a blob of credit card data; at minimum that payment token will have payment data. 
 - We know payment tokens can have a vendor-specific structure, i.e. tokens can have a type, and there may be a few types in the wild soon, Apple Pay just being one flavour for now. (Thanks @ntalbott for highlighting this!) 
 - It follows that the token data may have some vendor-specific metadata around it, but we can't necessarily know what that metadata looks like. 

Thus, a **Billing::PaymentToken** simply guarantees an interface to a `payment_token.payment_data`, `payment_token.type`, and `payment_token.metadata`. Note that we don't assume a token is necessarily a cryptogram, as was discussed earlier. 

### 2. Apple Pay Payment Tokens
To @ntalbott's point of not making payment tokens Apple-specific right out of the gate, a **Billing::ApplePayPaymentToken** is just a subclass of **Billing::PaymentToken**'; all the Apple-specific stuff is deferred to the **PaymentToken**'s metadata fields, and the `type` is simply `apple_pay`. This approach allows a gateway to use the same style of [payment source type checks](https://github.com/Shopify/active_merchant/blob/master/lib/active_merchant/billing/gateway.rb#L111-L114) seen for credit cards or checks. Now you can use the same interface to check if you're dealing with a payment token. 

### 3. Authorize.Net processing Apple Pay Payment Tokens
Here is also included a proposed implementation for Authorize.Net for processing Apple Pay Payment Tokens.

#### TODO
- [ ] Complete unit tests 
- [ ] Add remote tests for Authorize.Net processing of Apple Pay Payment Tokens. 

pls2feedback @edward @ntalbott @jnormore
Yeah, I meant for `metadata` to be a *private* interface that could be used in vendor-specific implementations, e.g.
```ruby 
def vendor_specific_field
  @metadata[:chocolate_chip_count]
end
```
so you could do `vendor_specific_token.vendor_specific_field` in a concrete token class. 
Does that make sense?