Default subscription payment token ignored when managing payment methods

[ChrisHardie]

When a customer uses the "change payment method" option for a Subscription, the saved payment methods/tokens presented are not rendered in a way that honors the default payment method already set for that Subscription, instead using a default payment method set from their user account, which can be different.

To reproduce:

1. Install WordPress, Woo Subscriptions, and the Woo Square payment method
2. As a user, create a subscription using a Square credit card (sandbox is fine)
3. As the same user, visit the subscription details and click "change payment method"
4. Enter a new payment method on the resulting screen and click the "change payment method" button
5. Observe that the resulting operation appears successful, but that if you return to the "change payment method" screen, the original payment method is still set as the default.

My understanding is that tokens for a user/customer and their subscriptions are stored in a few places. A subscription's default payment method is stored in the subscription's order post meta, with meta key _wc_square_credit_card_payment_token. A user/customer's payment methods/tokens are stored in the wp_woocommerce_payment_tokens table, and uses the is_default column to establish a default for the user, independent of individual subscriptions.

When processing the payment method change form for a subscription, the Woo Square plugin appears to correctly update the _wc_square_credit_card_payment_token meta field for the subscription object, but does not appear to update the customer/user's token default. This seems fine and to be expected.

But when the Woo Square plugin goes to do its part to render the change payment method form, in woocommerce-square/includes/Framework/PaymentGateway/Payment_Gateway_Payment_Form.php in get_saved_payment_methods_html(), it makes a call to WC_Payment_Tokens::get_customer_tokens() to retrieve the payment methods to display, which will always return the token configuration for the user, not the subscription.

The result is that no matter which payment method the users selects as the default for their subscription, the next time the change payment method form is loaded, it will use the user's default payment method, not the subscription's default payment method.

If I'm correct in this assessment, I think the most simple way to address this would be to alter the form rendering functions to use the subscription's existing default token instead of the user's default token. But it may be that there's something else about the logic of updating the stored/default payment method for a subscription that needs to be better synced with how the customer/user's tokens are stored and managed.