Allow dependency version overrides

[kszlim]

Problem description

ie. package A depends on C ~=1.0, B depends on C ~=2, C has versions 1 and 2, but the subset depended on in A is actually semantically compatible with version 2, so it would work, just that the allowed version specifier for A is overly restrictive (and likely the developer hasn't tested with that config specifically)

Would be useful to be able to do something like:

[dependencies]
A = "*"
B = "*"

[dependencies.overrides]
C = 2

Then version constraints for depending on C would be ignored and we just use whatever is specified.

Not sure if this gets more complicated when including pypi-dependencies.

[geoHeil]

See #1814

@ruben-arts as discussed on discord

[geoHeil]

See also #1817

[alexkreidler]

I would like to propose nested overrides similar to how NPM does it. 1, 2, 3

For example, suppose surya depends on opencv-python and I want a different version. You can just add an overrides section to your package.json specify the sub-dependency you want to override:

{
  "overrides": {
    "opencv-python": "2.3.0"
  }
}

For more specific overrides, you can target nested dependencies:

{
  "overrides": {
    "parent-package": {
      "sub-dependency": "desired-version"
    }
  }
}

You can also override a specific version of a package:

{
  "overrides": {
    "parent-package@1.0.0": {
      "sub-dependency": "desired-version"
    }
  }
}

Finally you can use the full flexibility of NPM package references:

Git specifiers:

"overrides": {
  "some-package": "github:user/repo#branch-or-commit"
}

Replacing a package with another package entirely:

"overrides": {
  "old-package": "npm:new-package@1.0.0"
}

I've used this pattern many times for

1. Patching dependencies with known security issues
2. Replacing existing dependencies with forks