Investigate bors for testing merge commits

[acfoltzer]

As I wrote in #526:

One important limitation I just noticed: the CircleCI build only runs on the commit of a PR's branch (what GH Actions labels the push), it does not automatically run on the merge commit (what Actions calls pull_request).

This raises the possibility that if a PR is not up to date with master, all of the CI might go green for a PR, we'll press the big green button, and the resulting merge commit into master will fail. The silver lining is that it will fail, since CircleCI runs on all commits by default.

It looks like there's an open (and popular) feature request to add testing on synthetic merge commits to CircleCI directly: https://ideas.circleci.com/ideas/CCI-I-926

This is also another case where using bors would help, since bors creates staging commits that are never behind master. Maybe it's time to set up bors for this repo?

I have only lightly interacted with bors when submitting patches to rust-lang projects. Let's investigate further to see whether we'd like to enable bors for this repo.

[aturon]

I will reach out to relevant folks on the Rust side to check in on their current experience around bors and any pitfalls we should be aware of.

[aturon]

So I checked in briefly with the Rust Infra channel, and confirmed a couple of things:

• The "bors" bot used by Rust is based on a codebase called "homu", which has been effectively unmaintained for some years. It's used only by Rust and Servo. Adopting literal "bors" from Rust seems unwise. (Further details here)

• There is, however, a "bors-ng" (next generation) project which is actively developed and has tools for setting up new projects: https://bors.tech/ (see also the also quite active forum here). That said, I'm not sure how widely used this tool is, so there's still some risk if we get too tied to it.

@acfoltzer lemme know if you'd like me to dig into either of these more deeply!