Suggest changing the version of a package, as well as its dependencies

Suppose I'm using `packageB`, which depends on `packageA`, and in my extra-deps I have

- packageA-1.0.0
- packageB-1.0.0

Additionally, this version of `packageB` has `packageA < 1.1.0` as a version bound.

Now I update `packageA` to 1.1.0. (Or maybe it's in the resolver and I update that.) So I have

- packageA-1.1.0
- packageB-1.0.0

which isn't a valid combination.

Right now, stack suggests that I fix this by adding `packageA-1.0.0` to my extra-deps. It would be great if it would also suggest changing the version of `packageB` that I specify.

I feel like this is more often what I need to do, especially when the problem is "the specified `packageA` is too new" rather than "the specified `packageA` is too old" or "there's no specified version of `packageA`". But even if it's correct less often than the current suggestion, having it in addition seems like it would be valuable.

A simple version of this might be to simply say something like: "try changing the version of `packageB` that you specify". That's not super helpful to someone who already knows to try that, but seems likely helpful to newcomers. A mild improvement on that might be to guess whether we should upgrade it (if all failing dependencies are above the version bounds) or downgrade (if all are below) or not guess (if it's not that simple).

More complicated would be to suggest an actual list of candidates. Maybe the ideal is something like:

- Get the list of available `packageB` versions
- Filter it for ones compatible with all other dependencies
- Of those, suggest up to four or five: the most recent revision of the current patch number; the most recent patch of the current minor number; the most recent minor of the current major; maybe the most recent major-with-the-first-digit-unchanged; and the most recent major.
- If there are no candidates after filtering, just suggest the same four-or-five, but from the unfiltered list, and note that they won't be fully compatible.

Though I'm sure there'd be edge cases to think about, and I don't really know what's possible with the current architecture. In any case I don't think this would need to be perfect to be useful.