Add interfaces to make wicket usable in an automated testing environment

wicket currently exposes functionality in two ways: the main wicket TUI (most functionality, including triggering rack setup), and clap-driven CLI subcommands (mostly anything that provides input, particularly the configuration for rack setup). When we get to the point where we want to run tests on real hardware lab environments, we will want to drive wicket in an automated way. A couple obvious options are:

1. Invest in testing and driving the wicket TUI (multiple implementation options are available here; e.g., something like expect that reads and navigates the TUI as-is, hooking into the event / replay stream a la the wicket debugger)
2. Expose more functionality in the CLI, since it should be straightforward to drive those automatically

IMHO 2 would be relatively quick and easy, but 1 might be more valuable (since it would give us more extensive testing of wicket itself).

Start by comparing wicket's TUI and clap-driven CLI entry points, then review how rack setup is triggered and how the debugger's event or replay stream works. The issue presents two possible approaches rather than naming files or tests; done means selecting and implementing an interface that can drive wicket for automated real-hardware lab testing.