…ert` (#2290)

* drop `@ts-expect-error`, because `inert` is available now

* fix logical error

We want to apply `inert` when we _don't_ have nested dialogs, because if
we _do_ have nested dialogs, then the inert should be applied from the
nested dialog (or visually the top most dialog).

* update changelog

* replace `useInertOthers` with `useInert`

* add `assertInert` and `assertNotInert` accessibility assertion helpers

* ensure the `main tree` root is marked as inert

As well as the parent dialogs in case of nested dialogs.

* fix nested `Popover`s not working

* update changelog

* Export explicit props types

* wip

* wip

* wip

* wip dialog types

* wip

* Fix build

* Upgrade esbuild

* Add aliased types for ComponentLabel and ComponentDescription

* Update lockfile

* Update changelog

* Update exported prop type names

* Make onChange optional

* Update tests

* Use `never` in CleanProps

Using a branded type doesn’t work properly with unions

* Fix types

* wip

* work on types

* wip

* wip

* Tweak types in render helpers

* Fix CS

* Fix changelog

* Tweak render prop types for combobox

* Update hidden props type name

* remove unused type

* Tweak types

* Update TypeScript version

* drop `d.enqueue` & `d.workQueue`

This was only used in tests and doesn't seem to be necessary.

* drop `handleChange` from the `ComboboxInput` component

This only emitted a `change` event, which Vue already emits as well.

* drop `onChange` from incoming props

This is an odd one. In Chrome this means that the `@change` is still
being called, but if we keep it, then the `@change` is _also_ called on
blur resulting in odd bugs.

Droping it fixes that issue.

That said, the `@change` is _still_ emitted and therefore the callback
is properly called and the `ComboboxInput` still can interact with the
`@change` event.

* update changelog

Let's wrap the test in `act` to get rid of the warning. In practice
(while testing in the browser) the actual warning doesn't seem to affect
the user experience at all.

The `act` function is typed in a strange way (`Promise<undefined> &
void`). Yet the actual contents of the `act` callback is returned as
expected. Therefore we overrode the type of `act` to make sure this
reflects reality better. (Thanks @thecrypticace!)

Also added an additional check to make sure the actual `container` is
available to extra ensure we are not lying by overriding the type.

* use the Dialog's parent as the root for the Intersection observer

We have some code that allows us to auto-close the dialog the moment it
gets hidden. This is useful if you use a dialog for a mobile menu and
you resizet he browser. If you wrap the dialog in a `md:hidden` then it
auto closes. If we don't do this, then the dialog is still locking the
scrolling, keeping the focus in the dialog, ... but it is not visible.

To solve this we use an `IntersectionObserver` to verify that the
`boundingClientRect` is "gone" (x = 0, y = 0, width = 0 and height = 0).

However, the intersection observer is not always triggered. This happens
if the main content is scrollable.

Setting the `root` of the `IntersectionObserver` to the parent of the
`Dialog` does seem to solve it.

Not 100% sure what causes this behaviour exactly.

* use a `ResizeObserver` instead of `IntersectionObserver`

* implement a `ResizeObserver` for the tests

* update changelog