Changing a shipment after the customer has paid recalculates the total

Here's a re-roll of #17, without tests unfortunately. This applies against 8.2.6

As a warning to anyone using this patch, like myself, this can prevent shipping from being added to orders when the addressbook is used. Since the patch checks `empty($triggering_element['#recalculate'])`, it prevents the shipping pane from running the rate calculations when the pane is initially loaded.

Lukas has some good points. I'm happy to work up a patch to push this further, but would like the logic to be reviewed/approved by maintainers before writing something up.

This patch doesn't yet have the tests added back in, but is a simple approach to addressing #23. The wording of the setting needs some thought, but the default setting of TRUE would leave sites as they are on checkout. Site builders could turn off automatic recalculation on whatever form displays they want then.

Needs schema

The 2 failed tests are from dev. I can add tests once we get feedback. NR for feedback from maintainers.
👍

I don't think we want to check for drafts. editing the shipment for the first time pulls up the methods, which we want to be governed by the form display setting, not the shipment state.

This patch simply omits the check for draft:
$shipment->getState()->value != 'draft' &&

Also for Lukas Von Blarer's comment in #21,

I have opened another issue for that, that references this issue.
📌 Improve shipping method behavior on admin shipment form Active

The patch provides the following implementation:

• When the setting is off (the desired setting for the default form display which governs the edit form), no calculation happens, and no methods are shown until the "Recalculate" button until clicked.
• When the setting is on (the desired setting for the checkout form display) calculation happens automatically.