AFAIK, we don't need the metadata.

https://github.com/actions/configure-pages/

Because we're not keeping the history of the gh-pages branch, we end up
with a new commit every time. Github refuses that we push that branch
because it doesn't match the history.

The docs [1] adds a CNAME file if you're publishing from a branch. But
since the action wipes the `gh-pages` branch every time, I think the
CNAME file will go away.

ghp-import has the option to recreate it every time.

[1]: https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/managing-a-custom-domain-for-your-github-pages-site#configuring-a-subdomain

* Run on push events to 'main' as the default branch has been renamed from 'master'.
* Add running the build job on pull_request events to allow testing builds of the
  website in advance.
* Scope concurrency to the workflow level, which allows for per branch runs to not conflict.
* Split the workflow into a build and deploy job. In the build job have the built website
  be uploaded as a run artifact. In the deploy job this artifact is then downloaded
  and and deployed to GitHub Pages.
   - For the deploy job, set the permissions to allow for the default GITHUB_TOKEN to perform
     the deployment.
   - Use the github-pages environment as required by GitHub Actions.
   - Run the deploy job on either:
      * push events to main (a merged PR)
      * workflow_dispatch events that happen on any branch, to allow for hotfixing

…-deployment

ci: Use GitHub Actions to perform deployment