buildbot should read config info, blocklist, etc from a repo-specific data file

[steven-johnson]

Currently, ~any change to our buildbot configs requires pushing a change to the master script, pulling it to the server, and restarting the buildmaster. This sucks. We should instead consider making this data-driven, based on a config file we check in to the Halide branch (instead of the buildbot repo); this should probably include things like:

• What LLVM branch(es) a given PR should be tested against (since a PR against Halide main may have different LLVM branches to test against, depending on where LLVM is in its release cycle)
• Allowlists/blocklists for tests under certain configs and/or buildbots
• Probably other stuff too

As a nice side benefit, it could make configuring release branches simpler, since the changes to the buildbot could be much easier to special-case on a per-Halide-branch basis.

Also: would allow for temporary tweaking of tests when developing a PR (eg, removing tests that you know are irrelevant to improve test time during dev)

[alexreinking]

Here’s something to get the bike-shedding started: we could create a new top-level .buildbot directory which contains subdirectories corresponding to our branches. In those directories, we would have configuration files (config.yml? Just not JSON, please) that override files in parent directories, like .clang-tidy does. That means we could have separate configurations: .buildbot/release/10.x/config.yml and .buildbot/release/11.x/config.yml that both inherit from .buildbot/release/config.yml, which I think would nicely factor out differences (ie. enable OpenGL testing in 11 but not 12).

PRs would be tested against the target branch, so PRs-to-PRs might become more common if, for example, you want to merge a Hexagon fix into a PR branch named hexagon/cool-new-feature and .buildbot/hexagon/config.yml only did Hexagon testing (and didn’t ask for Windows builds). Everything would still be tested before a merge to master, but the latency for PR-to-PR could be greatly reduced.

[alexreinking]

Also, this is sort of a duplicate/extension of #5269