feat: improve error message for handleHttpError and handleMissingId

[elliott-with-the-longest-name-on-github]

Closes #9592 by adding a line to both prerender error handlers explaining how to suppress or customize their handling.

I wasn't sure where to add a test for this, but happy to add one if someone knows a good location.

Please don't delete this checklist! 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 and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

[changeset-bot]

🦋 Changeset detected

Latest commit: 572b018

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/kit	Patch

Not sure what this means? Click here to learn what changesets are.

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

[benmccann]

I think that if the user implements handleHttpError this will be the message passed to that function and it might be undesirable to include "To suppress or handle this error..." there as you'll be getting that message even when you do implement the function

[elliott-with-the-longest-name-on-github]

Well now we're full-circle, ha -- what's the solution to the issue if not this?

[elliott-with-the-longest-name-on-github]

Actually, looking at the signature for the handler, I'm not sure this message would be undesirable -- we pass through the parsed information they need to do actual handling, so hopefully they're not trying to parse the message or something silly like that...

[dummdidumm]

I tend to agree with @tcc-sejohnson - the message is desirable IMO (won't merge for now to let others weigh in)

[Rich-Harris]

Ben's right, it's weird for this text to show up if the handler was implemented. Whether or not it's likely that someone will use message in their own handlers is separate to the question of whether the message is correct (but the whole reason it's provided is so that you can use it)