Make sure outgoing variants cannot be mutated after resolve
More specifically, this commit prevents from:
- adding a new outgoing variant after configuration has been resolved
- modifying the attributes of an outgoing variant after configuration has been resolved
12 Jun 17 397e26737e46e28f17ea89e160b2a8e2c1cac296
Treat various kinds of dependency resolution failures in more consistent ways.
- When a non-lenient view is used as a task input, then propagate any failure to select a configuration in the dependency graph during task graph calculation, rather than suppressing these kinds of failures and propagating later when the files happen to be queried. This now happens consistently whether fluid dependencies are used or not. The only difference between these is how much of the graph is traversed at task graph calculation time.
- When a lenient view is used as a task input, suppress configuration selection failures during task graph calculation and instead present them in `ArtifactCollection.failures`. Do this consistently regardless of whether fluid dependencies are used or not. Previously this kind of failure was propagated during task graph calculation for lenient views.
Also changed the error message on resolution failure to include what kind of query was being performed at the time to trigger the failure.
From an implementation point of view, separated the handling of selection failures from the code that produces the legacy resolution result so that this handling can be reused when the legacy result is not required (such as, say, when calculating the task graph).
29 May 17 cd7035ef3c0d461dc94f290bf56bb5ae638e7d20