Task configuration should support multiple configuration contexts, including some provided by a workflow template

While handling #883 (closed) I was a bit annoyed to have to create a dedicated task-configuration collection to host the "build_dep_resolver: aptitude" configuration because this configuration must not apply to all tasks in the workspace but just those started by the specific workflows that I was configuring.

While implementing task configuration, we were already a bit annoyed by configuration context being really limited to a single value because sometime we would like the context to be the target distribution, and sometimes we want it to be the build architecture. This was hinting at the fact that we should really support multiple configuration contexts.

And in the context of #883 (closed) it would have been nice if we could have added task_configuration_context: ["overlay-build"] to the template and then during task configuration, it would have looked up entries with context: overlay-build that I would have added to the default task configuration. This field would be copied over when creating child workflows or worker tasks creating a simple way for a specific workflow to opt-in in a specific configuration.

To make this deterministic, the order in which the configuration contexts are retrieved need to be specified by advance: the one provided through configuration is used first, then those dynamically computed by the task (and those should be stable between them too when they return more than one).