Add PWA functionality

[Harjun751]

What is the purpose of this pull request?

• Documentation update
• Bug fix
• Feature addition or enhancement
• Code maintenance
• DevOps
• Improve developer experience
• Others, please explain:

Resolves #2640

Overview of changes:

• Adds a flag --pwa to markbind init to initialize a MarkBind website with basic PWA functionality
• Adds a pwa field in site.json that can be set to true. This makes it so that the required lines to install the PWA manifest and service worker is included in the built html files.
• Documents how to update existing MarkBind sites to include PWA functionality

Anything you'd like to highlight/discuss:
When using markbind init --pwa to initialize a site, the default PWA values are like so:

It shows a dummy image and name.

I was thinking if it was possible to use the site.json file to include the configuration of the PWA manifest, so that it could be dynamically created every time. But then I thought that most likely the PWA manifest would only be edited once or a few times, so it wouldn't be worth implementing that.

So the intended workflow is for users to simply update the manifest directly if there are any changes to things like the site name, base URL, etc. Let me know if this is reasonable!

Additionally, the current implementation only allows for one service worker in the root of the site. I think it would be possible to improve upon this by adding a list field to the site.json that would allow the listing of all intended service worker paths in the application. However, I do think that this is a relatively niche case considering that MarkBind is not interaction-heavy and for documentation etc. Also I'm rushing for the CS3281 application due date heehee.

Testing instructions:
Further testing may be done by building the websites in packages/cli/test/functional/**_pwa and ensuring that install prompts are displayed on supported browsers.

Proposed commit message: (wrap lines at 72 characters)
Add PWA support

---

Checklist: ☑️

• Updated the documentation for feature additions and enhancements
• Added tests for bug fixes or features
• Linked all related issues
• No unrelated changes

---

Reviewer checklist:

Indicate the SEMVER impact of the PR:

• Major (when you make incompatible API changes)
• Minor (when you add functionality in a backward compatible manner)
• Patch (when you make backward compatible bug fixes)

At the end of the review, please label the PR with the appropriate label: r.Major, r.Minor, r.Patch.

Breaking change release note preparation (if applicable):

• To be included in the release note for any feature that is made obsolete/breaking

Give a brief explanation note about:

• what was the old feature that was made obsolete
• any replacement feature (if any), and
• how the author should modify his website to migrate from the old feature to the replacement feature (if possible).