Fixes #1349
Contributes to #1304

Context:

Testground defines a task.Task object with an anonymous Result field. The content of this field depends on the builder or runner used, for example:

• if the task is Build => Result contains an array of artifacts (probably docker images),
• if the task is Run, with a local_exec runner => Result contains nil,
• if the Task is Run, with a k8s or local docker runner => Result contains a struct with different Outcomes field.

That's fine for storage / serialization (when used as a wire format), but any piece of code that "receive" a task object needs to interpret the Result field by knowing about the runners. There are hints of the code required in the daemon/tasks.go code, see related PR: #1321. It create cyclic dependencies and bugs (because not all parts of the code use the same interpretation, see issue #1349).

Later it would be nice to rethink this data model.

Tasks

• introduce a data.DecodeTaskOutcome function, (a non-intrusive way to make sure we have ONE reusable way to compute task outcomes),
• make sure running a job with --wait will fail with exit code != 0 if the outcome is not a success.
• Return with an exit code 3 if the command failed during collect.
• Update tests: now that we check for actual outcomes, most test are failing