Improve error messages for provide conflicts

[Phantomical]

Currently, if you try to install a mod that provides X, but there is some other mod already installed that also provides X, then you get an error message that looks like

Unsatisfied dependency Y needed for: ...

This tells the users nothing about what is wrong or how to fix it. This commit is an attempt to improve the error message here. The new error message is now

X is needed for Y, but cannot be installed because it conflicts with Z which also provides W.

This commit changes:

• Instead of just getting a dependency chain, DependenciesNotSatisfiedKraken now takes a list of UnsatisfiedRelation. These also optionally store a reason that the relation could not be satisfied, which can then be used for better error messages.
• ResolvedRelationshipsTree.Candidates now explicitly checks for provides conflicts and records unresolved relations accordingly.
• In cases where there are no candidates and no unresolved relations then we redo the lookup without filtering in order to find modules that could have satisfied the relation, under different conditions.
• DependenciesNotSatisfiedKraken now takes the ProviderRejection into account when coming up with the error message.

I have also added some test cases that validate that the correct error message is emitted under a number of different conditions.

I'm not sure that this necessarily the right approach. It feels like I am pulling stuff into ResolvedRelationshipTree that isn't really supposed to be there. On the other hand the "if error then re-resolve to get unsatisfied candidates" bit does actually feel right to me, so I'm not sure what the correct balance is here.

---

The easiest one to test is probably this:

• Add the sol repo
• Install parallax continued
• Apply
• Install Sol-Configs

[coveralls]

Coverage Report for CI Build 25575170102

Coverage decreased (-0.09%) to 87.502%

Details

• Coverage decreased (-0.09%) from the base build.
• Patch coverage: 15 uncovered changes across 3 files (112 of 127 lines covered, 88.19%).
• 9 coverage regressions across 1 file.

Uncovered Changes

File	Changed	Covered	%
Core/Relationships/ResolvedRelationshipsTree.cs	44	36	81.82%
Core/Relationships/ResolvedRelationship.cs	64	59	92.19%
Core/Types/Kraken.cs	19	17	89.47%

Coverage Regressions

9 previously-covered lines in 1 file lost coverage.

File	Lines Losing Coverage	Coverage
Core/Games/KerbalSpaceProgram/GameVersionProviders/KspBuildMap.cs	9	57.14%

---

Coverage Stats

Relevant Lines:	9974
Covered Lines:	8592
Line Coverage:	86.14%
Relevant Branches:	2140
Covered Branches:	2008
Branch Coverage:	93.83%
Branches in Coverage %:	Yes
Coverage Strength:	1.8 hits per line

---

💛 - Coveralls

[Phantomical]

Okay, this should be good to go now. Changes:

• ResolvedByNew now stores a ResolutionContext that is meant to be a representation of the context it was resolved in. That is what gets used later on to do extra resolves in the error case.
• Fixed all the issues where a provides relationship was considered to conflict implicitly. That should now only happen if stuff is explicitly marked as conflicting.
• Updated the test cases to match.

In practice none of the stuff stored in ResolutionContext is modified. The only case where that might change in the future is the Installed list, so if we want to be safe I can update it to make a defensive copy here.

[Phantomical]

I think this covers all the possible error cases now:

• Conflicts via a provides relationship: A is needed for B, but cannot be installed because it conflicts with C which also provides D
• General conflict: A is needed for B, but cannot be installed because it conflicts with C
• Version conflict: Version conflict: A 1.0 is needed for B, and A 2.0 is needed for C, but both cannot be installed at the same time

It still special cases provides conflicts a little bit because I think having the context that "this error is happening through a provides relationship" is useful, but other than that the pathways are pretty much the same.