Allow explicit dependencies to resolve ambiguities

[lilatomic]

In case of an ambiguous dependency inference, we give the help text:

Please explicitly include the dependency you want in the dependencies field of a:a, or ignore the ones you do not want by prefixing with ! or !! so that one or no targets are left.

However, adding an explicit dependency doesn't actually resolve that. In ExplicitlyProvidedDependencies.disambiguated, if the target is in the explicitly provided dependencies, we just return. This results in the dependency being unowned, but included because of the explicit dependency link.

This MR rebuilds that function to use the explicitly provided dependencies to attempt to resolve an ambiguity. The logic is now as follows:

1. If there are no ambiguities, return
2. Use excludes to eliminate candidates. If there is a single owner, return it
3. Use includes to filter the remaining candidates (after excludes). If there is a single owner, return it

This algorithm change does result in changes to dependency inference. We can now resolve a situation which had both includes and excludes, and the excludes would resolve it. Previously, this would not be resolved. I don't think this will result in other changes in resolution. (I considered the case of the same address being included and excluded, but it seems that the excludes currently functionally take priority).

fixes #20806

[huonw]

(Thanks for looking at this, given #20806 affects 2.20.0, I've pre-emptively labelled this for cherry-picking back to that branch.)

[benjyw]

What's the status on this?

[lilatomic]

I think we said that this wasn't the right approach. In the slack thread we determined that we'd probably want to just give more/better warnings. The summary of the reasoning is that it's intentional that explicit deps function as overrides. So dep inference should not attempt resolution, and should instead defer to the explicit deps