Redesign logic around Run and Setup commands

[DavidBoike]

Describe the suggested improvement

For a long time, ServiceControl has been designed to have a setup mode and a run mode. The setup mode does setup operations, which most importantly includes creating necessary queues, but also opens the database, and could be made to do database migrations should an upgrade situation call for it.

Container support upends this paradigm, because requiring the separate setup step increases complexity in container deployment scenarios, usually by requiring some form of init container, which must also be outfitted with all the same settings as the primary container.

Yet, the historical separation has led the design to not cater to a container-friendly mode where with one usage of the HostBuilder, queues are created, the database is opened (only once), any migrations are executed, and then the app continues to run normally.

Currently this functionality is hacked in by executing a second instance of the executable as a child process to run setup, and then the "prime" execution continues normally. This is not ideal, but was done as a scope-limiting compromise due to the complexity of redesigning the startup logic to properly handle this scenario without leaving the chance for "unhappy surprises" littered throughout the codebase.

Additional Context

The following is an unorganized list of observations and context around these problems for a future point when this can be refactored/redesigned:

• All 3 apps evolved with independent startup routines. None of them does it quite the same.
• It's not possible to just run the SetupCommand and then run the RunCommand as you'd invoke two separate HostBuilders and DI registrations and the results could easily get messy with unintended consequences.
• ServiceControlComponent is designed to have Configure and Setup methods which is really unclear as to intent. Most of the Setup methods are just asking for queues to be created, but nothing prevents them from doing any other sort of initialization task, which wouldn't necessarily occur in a deterministic order.