Update NavigationTitle.svelte to support aria-owns

[kylejrp]

I'm able to define a aria-controls relationship between expand/collapse buttons in the trailing section. However, I'm unable to define an accessible parent/child relationship between a and its children s.

This PR should fix it (assuming I got the syntax right - I did this from GitHub's web IDE to avoid pulling the whole repo locally, so I may have got some syntax wrong)

Example possible usage (again, probably missing some required props, but this shows off the usage well enough):

<script lang="ts">
    import { Navigation, NavigationTitle, NavigationItem, Button } from "@stackoverflow/stacks-svelte";
    import { Icon } from "@stackoverflow/stacks-svelte";
    import { IconChevronUp, IconChevronDown } from "@stackoverflow/stacks-icons/icons";
    let expanded = $state(true);
</script>

<Navigation orientation="vertical">
    <NavigationTitle aria-owns="item-1 item-2 item-3" title="Throwaway">
        {#snippet trailing()}
            <Button type="button" aria-expended={expanded} aria-controls="item-1 item-3" onclick={() => expanded = !expanded}>
                <Icon src={expanded ? IconChevronUp : IconChevronDown} class="w16 h16" />
            </Button>
        {/snippet}
    </NavigationTitle>
    <NavigationItem href="#" id="item-1" text="Item 1" class={!expanded ? "d-none" : ""}/>
    <NavigationItem href="#" id="item-2" selected={true} text="Item 2" />
    <NavigationItem href="#" id="item-3" text="Item 3" class={!expanded ? "d-none" : ""}/>
</Navigation>

Which would result in this accessibility tree for the title (controls all three elements):

And this accessibility tree for the expand/collapse button (controls just the non-selected elements):

[netlify]

‼️ Deploy request for stacks rejected.

Name	Link
🔨 Latest commit	8bb8790

[netlify]

👷 Deploy request for stacks-svelte pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	8bb8790

[changeset-bot]

⚠️ No Changeset found

Latest commit: 8bb8790

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR