[docs] add service-worker example

[dummdidumm]

Decided against a service worker in the demo app because as @benmccann points out that get's really confusing/annoying really quickly. This PR previously contained a service worker in the demo app, and I got confused for a moment when running another app in preview mode getting served the old demo app, so I threw it out. Closes #2246

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• [x] 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
• [x] 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

• [x] 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[bot]]

⚠️ No Changeset found

Latest commit: beb11c9349cb7eca2a84001e36a720db616c0d4a

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.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

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

[benmccann]

I'm not sure how I feel about this. Service workers stick around in the browser so if you run one app with a service worker and then run a different app the service worker from the previous one is still there so it's a very strong form of caching. It makes debugging so much more annoying because I'm constantly having to remove service workers from reproduction reports and sometimes forget it's needed and it confuses users who don't know it will be happening. Personally I'm not sure I would add a service worker at all, but if we do I'd at least argue for it to be an option with a default value of false.

[dummdidumm]

The service worker hanging around resulting in confusion is a good point - but don't you have that problem anyway as soon as you use any form of service-worker? Also, it's only for the demo app. What if we prefix the file with an underscore and add a comment to the file and the about page that you need to "opt in" to the service worker, and why we do that?

[benmccann]

Yes, you'd probably have that problem with any form of service worker. Making it unused would be fine. Perhaps it would be clearer to call it something like disabled-service-worker.js than an underscore prefix?

[dummdidumm]

Removed the service worker from the demo, more details in the PR description