APP-2206: break apart tooltip component for custom usage

[mcous]

Overview

Following up on #381, as I went to integrate the updated Tooltip, I saw that several Svelte usage sites of this tooltip would benefit from the "separate target from described element" work I mentioned in that ticket.

This PR breaks the <Tooltip> into its constituent parts:

• <TooltipContainer> - a stateful wrapper
• <TooltipTarget> - a wrapper that attaches mouse/focus event listeners
• <TooltipText> - a presentational tooltip text component

You can continue to use <Tooltip>, or if that doesn't work for the UI in question, assemble the three parts however you need. In practice, I think this will mostly be "the visual target is different that the element on which we need to set aria-describedby.

I also upgraded the style calculation logic to automatically adjust scrolls/resizes/moves via floating-ui's autoUpdate.

Change log

• Add TooltipContainer, TooltipTarget, and TooltipText components that can be composed to create custom tooltips
• Wire in autoUpdate so the recalculateStyle component export isn't needed

Review requests

I have updated the playground and the Storybook, which are good places to start with this PR. The actual positioning logic is hard to test without Playwright, but if you do see anything that could use unit testing that isn't currently tested, please call it out!

The best way to test the autoUpdate functionality:

• Test the <SliderInput>
• Scroll up and down on the dev playground, where I've added a permanently visible tooltip

[mcous]

This appears to be a limitation of the Svelte ESLint plugin; it's a little buggy when it comes to correctly manipulating the parse tree when TS is involved (e.g. sveltejs/eslint-plugin-svelte#583).

I've been moving type exports to separate pure TS files to work around the issue. It's a little irritating to move the interfaces out of the component that uses them; but it's worth it to avoid losing type safety

[DTCurrie]

✅

[mcous]

Once last fix caught by @ehhong: if state="visible", the tooltip would flash in the top left of its container before moving into position. Resolved by ensuring that invisible is applied if the position hasn't yet been calculated. I think this might have been a regression introduced by my recent work, but now its fixed and there's a test in place