prefer JSON error responses over HTML in fetch case

[Rich-Harris]

closes #1931.

Today, if you have a route like this...

// src/routes/error/+server.js
export function GET() {
  throw new Error('yikes');
}

...then visiting /error will show you the fallback error page:

If you fetch the page with an application/json header, you'll get a JSON representation of the error...

...but by default fetch will get HTML. In most cases that's probably not that helpful.

This PR reverses the precedence during content negotiation, so that if a request has an accept: */* header (which fetch requests do, by default) it will prefer JSON to HTML.

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. All changesets should be patch until SvelteKit 1.0

[changeset-bot]

🦋 Changeset detected

Latest commit: 39df1b6

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

[Rich-Harris]

Marked this as draft because https://github.com/sveltejs/kit/pull/6497/files#diff-964f525b2136e97820d0ba82ceb5c6ab8d7a38c365fe198cfe855910500972cfR182 is unforgivable. Need to come up with some unambiguous way to communicate error information in a way that's comprehensible to both SvelteKit and users

[Rich-Harris]

Ok, I have an idea for what to do about errors more broadly, but I think it falls out of the scope of this PR, so I'm marking it as ready again