Combine `build.yml` and `github_pages.yml` into a single workflow file.
Having `build.yml` be a separate workflow file that `github_pages.yml`
calls has two problems:

1. All the inputs (and their types, descriptions, defaults) have to be
   duplicated in the two workflow files.

2. The reference to `@main` in `uses: "getpelican/pelican/.github/workflows/build.yml@main"`
   in the `github_pages.yml` workflow makes development and testing
   awkward.

For example let's say you want to send a pull request that contains
changes to `build.yml` and that also requires changes to
`github_pages.yml` at the same time. The problem is that the
`github_pages.yml` on your PR branch will still contain the reference to
`build.yml` `@main` so if you try to test the branch's version of
`github_pages.yml` it'll call the version of `build.yml` from `main` not
from the PR branch and will fail.

This commit move the build job from `build.yml` into `github_pages.yml`
but makes the deploy job optional: it adds a `deploy` input and will
only run the deploy job if `deploy = true` is passed.

Previously a user could test their build without deploying it by calling
the separate `build.yml` workflow. Now they can do it by calling the
`github_pages.yml` workflow and passing `deploy=false`.

This commit also moves the `concurrency` stuff from the workflow level
to the deploy level: it's okay to have multiple build jobs running
concurrently, just not multiple deploy jobs.

…le-file

Combine `build.yml` and `github_pages.yml`