Add ability to customize navigation announcer

[dummdidumm]

This introduces a new $app/a11y, which for now only exports setNavigationAnnouncer, which makes i possible to customize the navigation announcer, which should also solve the internationalization-part of it. The default stays untouched - which could be changed. It also could be enhanced such that one could turn it off if one returns null - up for discussion.
Closes #879

Before submitting the PR, please make sure you do the following

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts

[dummdidumm]

Should this be try {} catch {}ed?

[Conduitry]

Is this the best API for something like this? It feels a little weird to me. Could we instead have another file (similar to src/hooks.js) where you do export function navigationAnnouncer() { }, and that overrides the default one? I'm worried about this API being overly imperative rather than declarative.

[dummdidumm]

I chose to not put it in one place because when you want different announcements for different routes and you'd need to model that in one place, it could get awkward quickly, also colocation would be lost. Another thing is that internationalization is probably easier to add if you have it within your .svelte files because you can reuse the same mechanism.

[Conduitry]

Hm, okay. What about having it be a new <script context='module'> export from the .svelte file, or having it be a new thing in the response from the load function? I do agree that this is something that needs to be configurable, but I'm concerned about rushing into an API we'll regret, or that this will end up being one weird orphaned thing that nothing else in Kit behaves similarly to.

[dummdidumm]

Making this an export from context="module" feels strange to me at first, I reserved those kinds of exports to SvelteKit render options in my mind.
Returning it from the load function feels like mixing concerns to me. Then again, the concerns are already pretty mixed in that return object, so yeah that could be a good alternative. What would be returned though, a function? If not, how would you access the document title, especially if it's inside <svelte:head> and translated? Also how to pass these up to root.svelte? Currently the semantic is that the returned object is passed down, not up.

Totally get your concerns about not rushing this. One half of this PR for me is to get the discussion rolling, the other half was to get to know the SvelteKit codebase a little 😄

[benmccann]

Out of the options raised I think the current implementation or making it an export from context="module" make the most sense to me. I think I'd lean towards the export from context="module" option

[Rich-Harris]

closing in favour of #1305, per yesterday's discussion