Bug 1936098 [wpt PR 49594] - Re-design logic for commandfor form-owne…

…r combinations, a=testonly

Automatic update from web-platform-tests
Re-design logic for commandfor form-owner combinations

In whatwg/html#9841 the behaviour for
commandfor= as a form owner has subtly changed:

 - <button commandfor=> (implicit submit) that has a form owner
   now does nothing (so we will log a warning to the console telling
   the user that this is the case and they should add `type=button` to
   make it a command button).
 - <button type=reset command..> and <button type=submit command..>
   that have a form owner should do the behaviour explicitly laid out
   by their `type`, and ignore and `command`/`commandfor` attributes
   semantics. In this case we log a warning to the console telling
   the user that the command/commandfor are being ignored.

To keep changes light here, only the
DefaultEventHandler/CommandForElement logic has changed; a more
significant refactor might be needed to adjust `type_` to ensure it does not resolve to `kSubmit` implicitly, but that should be handled more delicately, I believe.

Bug: 382238696
Change-Id: I7d5583d34a2d615faeed80905816edb3f261d60d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6070260
Auto-Submit: Keith Cirkel <chromiumkeithcirkel.co.uk>
Reviewed-by: Mason Freed <masonfchromium.org>
Commit-Queue: Keith Cirkel <chromiumkeithcirkel.co.uk>
Cr-Commit-Position: refs/heads/main{#1393810}

--

wpt-commits: 3d3ea3af3e2049be17b4d881c957550c13637ba4
wpt-pr: 49594

UltraBlame original commit: c8018e3c22b59bc1daf9a5bef312e955ba15bccb