Add more helpful error messaging when a vulnerable dependency cannot be upgraded

[Nishnha]

This PR fixes the TypeError that was present in #5542 and re-introduces the commits from the original PR since they were reverted.

[mctofu]

What would the explanation be if it's one of the parents that doesn't have an update to a non locking version? I think that'd be the primary use case of this error as we might not get here if the vulnerable dependency doesn't have a fix available.

[Nishnha]

I think that's captured by this test in the vulnerability auditor https://github.com/dependabot/dependabot-core/pull/5645/files#diff-f0c4f0847c642ca1ba8627d73ce6dfc76f107816ac9916ef12d3ae5c4edce665R122-R149

I used a vulnerable range without a fixed version to make sure the vulnerability auditor would error, but I can update the test to #5645 (comment)

Then the resulting error from the ConflictingDependencyResolver and VulnerabilityAuditor is

(ruby) conflicting_dependencies_result
[{"explanation"=>
   "@dependabot-fixtures/npm-parent-dependency@2.0.2 requires @dependabot-fixtures/npm-transitive-dependency@^1.0.0 via @dependabot-fixtures/npm-intermediate-dependency@0.0.2",
  "name"=>"@dependabot-fixtures/npm-intermediate-dependency",
  "version"=>"0.0.2",
  "requirement"=>"^1.0.0"},
 {"dependency_name"=>"@dependabot-fixtures/npm-transitive-dependency",
  "fix_available"=>false,
  "fix_updates"=>[],
  "top_level_ancestors"=>[],
  "explanation"=>"No patched version available for @dependabot-fixtures/npm-transitive-dependency"}]

The error message from the vulnerability auditor is the same though. Would you expect it to list out the locking parent too?

[Nishnha]

I removed the test for "with an unsatisfiable vulnerability" in bf62aaf because I don't think we can reach that code without also having conflicting dependencies.

I updated the test with both "conflicting dependencies and an unsatisfiable vulnerability" to use an invalid version range for the vulnerability in a8d6b3a.

Our @dependabot-fixtures setup is not complex enough to test this scenario using valid vulnerability ranges, but it does seem like a case that can occur in a project, so I want to keep test coverage around it.

[Nishnha]

I opened #5672 to create and test a scenario where a valid vulnerable version range is blocked by a locking parent dependency