Generalize Container/Host Task execution location logic

[jameswilson]

Refactor the “where to execute this task?” logic out from Spark\Robo\Plugin\Commands\DrushCommand so that any Robo command inside spark can leverage it. This is a blocker for the GDPR dump sanitization task.

One approach would amount to moving the "isContainer" variable up to Spark\Robo\Tasks, and changing how the task execution code works in Tasks to take the container name and "isContaner" logic into account.

Here is how we're current using isContainer:

https://github.com/BluesparkLabs/spark/blob/38f19897a4f8db2e2e0e5e6c74646710072fa04c/src/Robo/Plugin/Commands/DrushCommands.php#L30-L43

Another challenge will be figuring out how to generalize certain caveats, like the execution directory, which appears to be different when inside the container versus outside. In this snippet we are changing both the webroot location as well as the path to the command binary drush when inside the container.

https://github.com/BluesparkLabs/spark/blob/38f19897a4f8db2e2e0e5e6c74646710072fa04c/src/Robo/Plugin/Commands/DrushCommands.php#L13-L23

/cc @balintk @brants

[jameswilson]

Would it make sense to have a general way for Command files to override or instantiate their own default container name where their tasks should be run?

[jameswilson]

Eg the DrushCommand.php constructor would set $this->container = 'php'; the DbCommand.php constructor would set $this->container = 'db';