This PR adds the following CLI commands and the necessary restructuring to make them possible:

• localstack start --detached: starts the localstack container in the background
• localstack wait blocks until localstack is running (the ready marker has been printed)
• localstack logs --follow tails the log output of localstack

The most noteworthy changes and improvements:

• The most fundamental change is that, in the start_infra_in_docker routine, the terminal output no longer comes directly from the docker run command itself, but is forwarded to a logfile in the TMP folder that is then tailed using a new uiltity called FileListener (that is platform independent, but needs to be tested on Windows). that log is then printed to stdout asynchronously, while waiting on the docker run command to stop (via the Server abstraction)
• added the CLI commands
• The part of start_infra_in_docker that was building the command is now separated into a holder object (LocalstackContainer) and a configuration routine (configure_container)
• adds a dedicated test step for bootstrapping (which involves starting up and tearing down the container).
• FORCE_NONINTERACTIVE is not used anymore (there's no obvious reason to have an interactive tty docker session when only logs are printed to stdout)

Some things that I hope will be useful in the future:

• with the LocalstackContainerServer, you can now treat localstack as you would any Server implementation. this can be used in tests to start up and tear down localstack without mucking about with low-level docker commands.
• the LocalstackContainer object can be passed to configuration hooks that modify the startup behavior, without being part of the actual startup routine
• being able to start localstack in detached mode via the CLI paves the way for a new type of UX

Things that need improving:

• more bootstrap tests! especially for testing custom docker flags and volume mounts
• The way the logfile is resolved for the LocalstackContainer is sort of hacky
• The CmdDockerClient is used to allow the --privileged flag for the container startup
• extend the item types VolumeMappings and use that throughout the ContainerClient abstraction (some ideas in this gist: https://gist.github.com/thrau/b450e79c6a08d965ca2731b26065b67c)
• the ContainerClient abstraction does not provide any way of capturing or streaming the output of commands to something outside of the abstraction. i added default_out_file as a workaround, which is handed down as outfile parameter to the underlying subprocess to be able to capture the output of a run_container execution
• the CI build step starts up localstack containers with the latest image, not the one built in the pipeline. this is only an issue when there is new interaction between the cli and the container runtime.