The approach using the `SelectorObserver` is much more reliable to fire
the outlet connected and disconnected callbacks.

It's now matching against the selector provided in the
`data-[controller]-[outlet]-outlet` attribute instead of just looking
for elements which have a `data-controller` attribute to appear.
Previously, when a `data-controller` appeared we checked it's attribute
value to see if it was relevant as an outlet for the current controller.

Using the `SelectorObserver` we now solve an edge case where the user
would dynamically add/remove an attribute to the outlet element which
would then make that element relevant or not relevant anymore as an
outlet for the current controller. We need to know that so that we can
reliably fire the outlet callbacks. Previously I wouldn't have fired the
callbacks.

For every outlet we define we now create a separate instance of the
`SelectorObserver` which also handles that we just match the relevant
outlets by adding the `data-controller~=[outletName]` selector to the
CSS selector we lookup.

…rrent instance gets connected

There was an edge case where outlets wouldn't fire the outlet callbacks 
if they appeared later in the DOM but the current instance had a 
"dependency" on them.

To solve this the OutletObserver now "notifies" it's dependents that 
it conencted so they can refire the matching elements via the 
`refresh()` function of the ElementObserver.