Figure out way for PRs from forks to work with static site generator

[LukeMondy]

Relating to: #20

A possible solution is to switch back to pull_request_target, and do something like suggested here: #20 (comment) - that is, figure out what the real PR SHA is, and check that out manually.

The real issue is that forks can't see any github.SECRETS, which means the 'deploy the generated site to a git repo' doesn't work, and so we need a work around.

[lsf37]

I don't think there is a good GitHub solution for this, and the html-preview thing we are using currently has its own problems (takes sometimes extremely long to serve CSS or doesn't do it at all).

@wom-bat do you think it would be possible for the web server to host preview branches under a specific URL for a limited time?

So if we had a PR with some branch name x, the server would fetch x and serve it under something like stage.sel4.systems/x/. It could either monitor the GitHub repo directly for new pull requests or a GitHub action could poke some web hook to make it check out the repo.

We'd need to restrict this to PRs coming from org members, otherwise we'd be hosting arbitrary content on that preview. Maybe later extendable to some additional scheme similar to the ssrg-bamboo bot.

The preview branch should disappear from stage after the PR is merged or closed.

[lsf37]

This would also mean that we can run the validator and link checker on the live site and see their output in the error log, without needing to go through post processing and commenting, which keeps breaking.

[lsf37]

Another way to make the comment action work from forks is using a separate workflow for that part: https://docs.github.com/en/actions/reference/events-that-trigger-workflows#workflow_run