Reassign subscriptions and recurring orders when an initial order is reassigned

Re-roll of patch in 17 with D10 compatibility fix.

I'm not entirely sure of the approach here. Is it truly a given that reassigning the initial order of a subscription should always reassign the subscription and every order ever associated with it? I may not understand the use case, but this seems like a pretty big assumption. At the very least, we're talking about exposing the PII of the previous owner to the new owner without ever providing an opportunity for this decision to be reviewed.

Also, why wouldn't the original user still own their prior orders? If this were a donation to a 501(c)3, for example, the original donor would need to maintain access to their historical order record for tax deduction purposes.

I think I'd feel a lot more comfortable with this being governed by an opt-in checkbox on the order reassignment form. In that case, the behavior would be explicitly enabled, and we would even be able to spell out exactly what would be assigned to the new initial order owner along with the order itself. We might even consider multiple checkboxes: one for reassigning the subscription and another for reassigning all recurring orders associated with the subscription.

Finally, I'm not sure what it means for the subscription to be reassigned but the payment method be someone else's. It could be the act of reassignment needs to be paired with a new payment method reference - one already owned by the new user. Maybe knowing more about the current use cases could clarify what should happen there, but moving a payment method should definitely require an explicit opt-in and may also need to support selecting a different payment method associated with the new user.

The use case is anonymous orders. This is especially relevant for subscriptions that grant special access. Someone buys a recurring membership anonymously, and then the order gets reassigned to a real user (which I believe is part of a standard commerce feature). Perhaps this approach is too general, and we should just be responding to reassignment of anonymous orders.

Our initial use case was also anonymous checkout. The problem with adding a checkbox is that this should be an automatic process that fires after checkout. Perhaps, the action happens by default when the uid is 0, but there's a checkbox when manually moving an order?

Finally, I'm not sure what it means for the subscription to be reassigned but the payment method be someone else's

`Drupal\commerce_payment\EventSubscriber\OrderAssignSubscriber` is already moving the payment entity in commence core :)