[12.x] Implement new proration and pending updates

[driesvints]

Provide support for new always_invoice proration and subscription pending updates.

The proration changes now offer full support for all new Stripe proration options, including always_invoice. All of the xAndInvoice methods have been updated to make use of this option. Using any xAndInvoice method will apply the always_invoice proration behavior. This reduces the api calls from two to one. There might be some slightly changed behavior in certain situations where you were explicitly expecting the invoice endpoint to be called.

This PR also provides support for subscription pending updates. There's three new methods which can be called right before swapping plans, updating quantities, adding or updating subscription items.

• allowPaymentFailures which is the default behavior and will allow subscription changes even when a payment failure occurs.
• errorIfPaymentFails which was the past Stripe behavior from before the 2019-03-14 update and will hard fail any update with a failed payment.
• pendingIfPaymentFails will place any changes as pending until the payment for the latest invoice was successful.

Pending updates can be checked with the new ->pending() method on the subscription model and they can be cancelled by calling the new ->void() method on the invoice object. The latest invoice of a subscription can be called with the new ->latestInvoice() method on the subscription model.

Breaking Changes

• If you were applying noProrate and using any xAndInvoice method afterwards, that usually should not generate a new invoice. With the new behavior any xAndInvoice method will always generate a new invoice and undo the noProrate behavior.
• Although the remaining behavior should remain the same, there might be a slightly difference in behavior if you were specifically relying on the invoice to be explicitly issued through the invoice endpoint with any xAndInvoice method. This is now done in one go with the always_invoice proration option. Please make sure to test this scenario before deploying to production to make sure your billing flow works as expected.
• All underlying proration logic has been updated to accommodate for the new logic. If you were relying directly on the $prorate property, this was now renamed to $prorationBehavior. Similarly, the setProrate method has been renamed to setProrationBehavior.