Proposal: Mutation Observation Syntax

[seanpdoyle]

Add attribute-level support for monitoring changes to attributes on the
marked element and its descendants.

The data-mutation syntax draws direct inspiration from the
[data-action] syntax for routing browser events.

Similar to how the Action syntax supports event listener options,
the Mutation syntax would support MutationObserverInit options like
!subtree.

The proposed hooks only cover attribute mutations, since the proposal
made by hotwired/stimulus#367 should cover childList type
mutations like the addition or removal of controller targets.

One alternative could involve combining [data-mutation] and
[data-action] into a single DOMTokenList keyed by the existing
[data-action] attribute and using additional symbols
like @... or wrapping [...] as a differentiators (e.g.
@aria-expanded->disclosure#toggle or
[aria-expanded]->disclosure#toggle).

Another could push this responsibility application-side by introducing
more publicly available MutationObserver utilities like those used for
DOMTokenList parsing or deconstructing the [data-action] directives.

Once available, those utilities could be used by consumers to listen for
their own mutations and "route" them to actions by combining action
directive parsing and
Application.getControllerForElementAndIdentifier(element, identifier)
to invoke fuctions on a Controller instance.

Notes

The proposal in its current form only includes changes to the test suite for the sake of starting the conversation and demonstrating the concept and usage.

If there's interest, exploring the implementation details can follow.

[dhh]

As mentioned on #445, I think adding more syntax in the HTML for this is probably going to tip the complexity scales too far. I think the pattern we have with targetChanged is the way to go and extend. As well as considering a general purpose mutation observer helper function where you can get very specific.