Currently the process for standing up new Windows CI tasks (which use LUCI) in flutter/plugins require changes to recipes in a separate repo. This makes them much more cumbersome to write, test, and land than changing Linux or macOS tasks (which use Cirrus). In discussion with infra folks we can set up a short-term solution to this that can be easily migrated to the eventual long-term in-repo-management system once that's implemented, using a system like what's currently used for Cocoon:

• Write one generic recipe that constructs LUCI task specifications dynamically from configuration files in flutter/plugins.
• Have the steps of those tasks implemented as scripts in flutter/plugins whose paths are set in the config file.

The Cocoon version has a single config file since there's just one target; for flutter/plugins we generally want the ability to run fundamentally different tests in different targets in order to make it easier to see what is failing, so we'll add one more variable to that process that allows the builder spec (in .ci.yaml) to set the config file to use.

Once that's in place, adjusting an existing LUCI target will just be changes to local scripts and/or a local config file, and standing up a new target will just be new scripts and a new config file.

My plan is to use (extremely minimal) bash for the script files, in order to be consistent with Cirrus configuration (and because bat is substantially worse, and would add a new language). The Windows bots have bash, and we're already using it for the existing Windows plugins recipe without issue, so it shouldn't be an issue here. It will be a little more annoying than Cirrus still since we'll need to make trivial bash scripts for every step, vs. just being able to have them inline in the one file, but still a huge improvement over writing them in python in a separate repository.