[13.x] Refactor payment exceptions

[driesvints]

This simplifies the payment exceptions within Cashier. Atm we were still rolling separate exceptions for the different statuses of a payment. But these types of statuses can easily be derived from the encapsulated payment intent object. In general, it's unlikely that someone implementing Cashier will make abundant use of these different types of payment exceptions. We also only document the use of the parent IncompletePayment exception in our docs: https://laravel.com/docs/8.x/billing#handling-failed-payments

The sub types are currently documented but probably that's not needed as you'd usually just make use of the parent exception. If you really need to differentiate between them, then the Payment object has helper methods to do just that.

This PR also makes ->validate() on the Payment object throw the exception for payments with the status of requires_confirmation.

[taylorotwell]

So what if they did need to know the specific type of problem? What would the user do then?

[driesvints]

@taylorotwell the type is contained within the payment object:

$exception->payment->requiresPaymentMethod();

If you really need to differentiate between them, then the Payment object has helper methods to do just that.