`UpgradableConstructor` should only apply `formAssociated` on-demand and throw in case of conflicts

[jmsjtu]

Description

The introduction of formAssociated on the UpgradeableConstructor in #3695 has introduced unintended observable changes to custom elements.

This is causing the browser to identify LWC components as form-associated elements. This is an issue for components that contain form inputs, as secondary clicks for labels are now dispatched on the label-associated host element instead of any internal form inputs (e.g., input).

A repro can be found here.

Click the label element ("awesome checkbox" text) to observe the differences in behavior when formAssociated is true vs false.

The checkbox will check when the label is clicked with formAssociated=false but will not when formAssociated=true.

[git2gus[bot]]

This issue has been linked to a new work item: W-15001648

[nolanlawson]

New design, which aligns with LWS:

• The first definition of a component (e.g. <x-foo>) gets to set the class's formAssociated-ness to either false or true.
• The following definitions are subject to a check:
  • If there is an existing definition for the tag name (e.g. <x-foo>) and the existing definition's formAssociated value does not equal the new definition's formAssociated value, throw an exception with clear explanation.
  • E.g.: <x-foo> was already registered with formAssociated=true. It cannot be re-registered with formAssociated=false. Please rename your component to have a different name than <x-foo> (link to lwc.dev documentation)