Fixes #1493

Dear reviewers, extra care is taken to have clean commit steps. In case we want to split this PR.
It will be much nicer to review by going through the git history (in github: open the first commit then use the Prev / Next buttons).

• Implement pick and toml and withEnv
• Update composition
  • Split composition.go into 3 different files (prepare, validate, and data)
  • Simplify the validation processes to clarify validation/preparation
  • Fix encoding/decoding using mapstructs
  • Add the runs field
• Implement client-side runs field
  • add an option to build and run a single id (fail in other cases)
  • add an option to gather results into a CSV
  • we start multiple runs on the client side for now (build happens once)
• Turn runs step into a Strategy object to make follow-up refactoring easier
  • This lets us "name" operations and reuse them more easily
  • This prepares for simplification (remove duplicate code in build and run operations) and testing (mock API calls).
• Implement server-side runs field
  • Add validation
  • Process a run with the runids parameters
  • Fix the composition returned in the task
• Add tests, etc.

Known issues

the runs field is processed client-side

We have two options when sending a composition with multiple runs either:

• create one task that contains a group of runs,
  • This is the ideal way to do this, and I'd like to implement this later. It means cleaning up the way we represent tasks and gather outcomes, etc. At the moment even outcomes between two runners are processed very differently. I prepared this feature by this workflow as much as possible.
• create multiples tasks, one for each run,
  • This is the less intrusive way. We could do it server side, but then the server has to hold long-running states, we have to serialize it, etc. Which will end up looking like a weak implementation of task groups. Since we also want to implement retries and improvements to the client's CLI, I moved the code there.

Follow-up Tasks

See #1493