Goma will be turned down Real Soon Now, and local dev workflows for RBE require the compiler proxy to be started and stopped around each ninja invocation. et knows how to do that in the context of executing engine_v2 build configs, and can provide a smooth migration pathway from Goma to RBE. A difficulty is that the engine_v2 build configs were not designed with local dev workflows in mind, and so do not neatly fill the need being served by direct invocation of tools/gn + ninja.

Some local dev builds have been described in ci/builders/local_engine.json, but these are not yet running in CI, and the names of the builds in that file duplicate some of the pre-existing CI build names.

While not fulling solving #145185, I am going to alleviate the difficulties above with the main goal being to mitigate the disruption due to Goma's turn down. My plan is the following:

1. Change the name of builds outside of local_engine.json by prefixing them with ci/, and add a test to ensure that remains consistent.
2. With the goal of running each of the local_engine.json builds in CI on each platform, I will make by-hand internal copies of each config. The name of each config will be prefixed by the name of the platform it will run on, e.g. macos/host_debug to avoid name conflicts with the ci/ builds. I'll add a test for this to ensure it remains consistent. (Eventually local_engine.json should be machine generated, but that's not a requirement for the Goma -> RBE transition, so we should put that off until later.)
3. With the goal that et build -c host_debug etc. will continue to work on all dev platforms. I will teach et that a config name passed to et build and et run that does not have a ci/ prefix should have the os name prefixed to it so that it can be found in local_engine.json.
4. I will add human-readable descriptions to all builds, and teach et about those fields to report them in help messages, etc.

That last one is optional, but I think I'll need it for my own sanity.