Add an unsatisfiability check method to `SpecifierSet`

[notatallshaw]

This is a follow up to #776 which failed to progress due to the nuances of Python package version specifiers making it not clear if it's possibly to "reasonably" simplify SpecifierSets.

However, in a lot of cases for resolution what's more important is knowing whether a specifier set is unsatisfiable or not, for example:

• Unsatisfiable: <1,>2
• Satisfiable: >1.5,!=3.*

As a resolver if you know a specifier set is unsatisfiable you can skip collecting the versions available, which can potentially save you a lot of time as you may need to do network requests or build source trees to determine the versions available for a package.

This would ideally be part of packaging as accurately following PEP 440 to determine unsatisfiability is highly non-trivial.

As long as there is no objection I plan to raise a PR shortly, I have done most the work to implement this already, I am ironing out some final test cases around extreme edge cases (such as arbitrary equality).

P.S. This also follows #897 as it should now be true that if SpecifierSet({expr1}) is unsatisfiable, so is SpecifierSet({expr1},{expr2}), this is an important invariant for resolvers, and without it determining the unsatisfiability doesn't allow you to make any further logical inferences.

[akhmerov]

Even a minimal version that would return unsatisfiable/maybe satisfiable/satisfiable would be useful for checking whether to remove version-dependent code. A few of my projects have:

if dependency_version not in SpecifierSet("<min_version"):
    backwards_compatible_code

Checking if SpecifierSet("<min_version") is in principle compatible this with project dependencies would allow to easily find which of these code paths can be safely removed.