Refactor `build_service` to utilize finite state machine

[tjtelan]

Almost at a point where the current implementation is correct enough as written in a procedural style. It is getting a little hard to maintain the mental model all in the single build_start function.

The idea I have is to turn the state machine into some kind of iterator where the state transitions can be split up more formally.

A lot of the ground work will come from the orb.yml config parser

• [ ] Implement Iterator trait for OrbitalStage
• [ ] Implement OrbitalStageCommand and implement Iterator trait

There are many small state machines that I'd like to abstract out of build_service, and into agent_runtime's build engine so I can test them more easily.

[tjtelan]

This looks like a good guide to base my implementation https://blog.yoshuawuyts.com/state-machines/

[tjtelan]

Re-thinking the stance on creating an iterator for the orb.yml parser to align with the finite state machine. A unrolling the build config into a vector of commands that I can pop() off after each step may work, but I have to think about how important it might be to keep past commands. If it is very important, I might do something that tracks the current index of the commands w/ respect to all of the commands.