Support merge queues for CI workflows

[mhucka]

This adds support for GitHub merge queues. Merge queues help make sure a pull request is compatible with other changes ahead of it. It's being used in Quantumlib projects successfully.

This PR also adds missing copyright headers to the workflow files.

[MichaelBroughton]

Can put these in, but given our past track record with CI changes going sideways and the fact that this is solving a problem we currently don't have (too many CI runs at once from so many incoming PRs) I'm a little skeptical.

[mhucka]

Can put these in, but given our past track record with CI changes going sideways and the fact that this is solving a problem we currently don't have (too many CI runs at once from so many incoming PRs) I'm a little skeptical.

We've been using merge queues in most of our other repos the whole year, and they've been working well.

This is not about having too many CI runs at once. Without merge queues, every time you merge a PR, every other unmerged PR needs to have its branch updated manually, which in turn invalidates the previous CI runs for that PR and triggers a fresh round of CI check runs. That in turn means having to wait for the checks to finish before being able to merge that PR, because the merge option isn't available until the checks finish. It's a serial, manual process.

Merge queues instead enable "merge when ready" automation, in which GitHub will queue up multiple PRs and automatically do the branch updates and merges if they pass. It means that once a bunch of PRs are approved, you can just do 1 action for each approved PR and you're done.

Case in point: I did 6 small PRs in a row today. The build check takes 25+ minutes. After you approved them, I would have had to keep coming back at half hour intervals to sequentially update the branches, wait until the checks finish before merging that PR, then go to the next one and update the branch, etc. – a huge waste of time.