This adds constraint_regions() which is a utility that takes a set of python version constraints and spits out the distinct regions that those constraints split the world into.

For instance: input >=3.6 and >=2.7,<3.0.0 || >=3.4.0
output <2.7, >=2.7,<3.0.0, >=3.0.0,<3.4.0, >=3.4.0,<3.6, >=3.6.

I am expecting views on whether this is the right place for such code to live, and what the method should be called, and requests for unit tests, which we can get to in due course...

The motivation for this is that I think we need it to fix a particularly icky poetry export example python-poetry/poetry-plugin-export#32. There, the tree-walk at some point finds the requirement:

{version = "*", markers = "python_version > \"3.6\" and implementation_name != \"pypy\""}

and correctly decides that only ipython 7.16.3 can satisfy this. But that causes it to add a ... or python_version >= "3.6" ... marker for ipython 7.16.3, which sadly overlaps with the markers on a newer ipython version.

My intended fix is to split up the python version space and when adding a requirement during the walk, actually add several requirements, one for each range of python versions. That allows the locker to limit the ipython 7.16.3 selection to >3.6,<=3.7 and all is right again.

(I'll follow up with an MR in poetry, hopefully clarifying the above).