Investigate the possibility of refactoring `Guest.execute()` into `executor`/`execution_driver` abstraction

[thrix]

Proposal

Consider implementing an executor/execution_driver abstraction that abstracts the usage of guest.execute more explicitly.

This can then be specialized granularly for each SSH execution types to support bootc or not, and inside the bootc a similar split for how to create the bootc image and how to provide it to each virtual, beaker, etc. provision types.

The idea is that while mixins would all be used together (as artemis, beaker, connect, minute, and virtual guests are SSH-backed and would include both SSH and bootc mixins), they would still have distinct implementations for each one.

Original discussion

#4525 (comment)

[LecrisUT]

My vision on this is to move all of the logic we have in the guest.execute and similar under its own class that can change for each guest based on the facts gathered (similar to how the package_manager changes based on those). We can then also have it own adjacent stuff like StopWatch. A quick sketch

class Guest:
    executor: Executor

    def _post_init():
        # This is used in the fact gathering
        self.executor = self.initial_executor(self)

    def _post_gather_facts():
        # From here on this one is used and would be aware of gathering commands etc.
        self.executor = self.executor_from_facts(self, self.facts)

    def execute(...):
        return self.executor.execute(...)

[psss]

Just starting the discussion on this...