Integration test coverage for re-resolving configurations

[lptr]

• Warning emitted and change ignored when Configuration mutated after resolution:
  • [x] Dependency added/replaced/removed
  • [x] Set of parent configurations changes
  • [x] ResolutionStrategy modified
  • [x] Set of exclude rules changes
  • [x] Calls to ResolvableDependencies.beforeResolve and afterResolve
  • [x] Any mutation to parent configuration (even if that configuration has not been explicitly resolved)
• When a previously-resolved Configuration is set to a 'mutable' state and not mutated:
  • [x] Use of FileCollection API uses previous resolution result
  • [x] New and existing ResolvedConfiguration instances use previous resolution result
  • [x] New and existing ResolvableDependencies instances use previous resolution result
• When a previously-resolved Configuration is set to a 'mutable' state and is mutated:
  • [ ] Use of FileCollection API forces re-resolve and uses new resolution result
  • [ ] Use of new and existing ResolvedConfiguration instances forces re-resolve and uses new resolution result
  • [ ] Use of new and existing ResolvableDependencies instances forces re-resolve and uses new resolution result

[lptr]

• [x] Also need to update spec to reflect that ResolvedConfiguration and ResolvableDependencies are not live objects.

[lptr]

"When a previously-resolved Configuration is set to a 'mutable' state and is mutated:" -- this doesn't make sense. The only way when a resolved configuration can be re-resolved is that it was first resolved for task dependencies only. In that state we cannot access any of the three results (files, ResovledConfiguration or ResolutionResult) without triggering a full resolve first, so there's nothing to compare.

I think the rest of the tests cover re-resolution in enough detail already.

[lptr]

I've removed the corresponding part from the spec, so all of this should be done now.