FPGA CI feature requests

Over in FPGA land we have a few, somewhat unique challenges (some of our own making) that pushed us to using GHA and self-hosted runners to meet our current CI needs vs buildomat and I wanted to document why here as buildomat may grow enough features to warrant looking at it again in the future.

• Large toolchains (40GB+) which aren't well-suited to being installed on-demand. (Solveable with custom VM images I know)
• A split-brain build system: we're using cobble for our bsv-based designs and buck2 for our vhdl-based designs.
• A mono-repo structure where the shared and common IP and the projects are all in the same tree.

Our naive version of CI was "build all the things" and worked ok for one build system and a set of projects that built relatively quickly, but as the designs got larger (looking at you sidecar main FPGA) build times increased, leading to long lag of an hour or more while CI runs before changes can land. In our current world where much work is going on in the new build system for cosmo, having to spend 45mins or more rebuilding sidecar main controller for example is both a waste of time and compute energy.

Feature need 1:
We'd like a way of conditionally running jobs with some change filtering ala https://github.com/dorny/paths-filter does in github actions. This feature allows us to drastically cut down amount of build time required by only naively building cobble-based things or buck2 based things based on the change set.

Feature need 2:
We'd like a way of preserving interim build artifacts. Our build systems (cobble and buck2) are very good at tracking the dep tree and only re-doing the minimal amount of steps necessary. For our bluesim cases, this cuts a 17min run down to 4mins by not having to rebuild a bunch of stuff that didn't change because we're re-hydrating the next build with the previous build results. This looks to be related to https://github.com/oxidecomputer/buildomat/issues/32

Feature need 3:
These things are large and relatively stable, we'd like to target our own infrastructure vs aws so being able to run these on colo/dogfood/some-other-oxide-rack would be awesome. Related to https://github.com/oxidecomputer/buildomat/issues/13

That said, if neither of these features fit well for buildomat's roadmap I think it's very understandable. In the very very long-term, I'm interested in moving to a remote execution setup, which is probably also not a great fit for buildomat's core service. buck2 supports the protocol used by https://bazel.build/community/remote-execution-services and we may consider looking in that direction if our FPGA use continues to increase and our designs get much larger.

Review linked issues #32 and #13 and the three requested capabilities first; no repository files or tests are named. Done would require an agreed scope and implementation path for change filtering, interim artifact preservation, and execution on non-AWS infrastructure.