Time to rethink `prefered constraint sequence`?

Our current implementation of VersionRange assumes that information regarding the logical operation (AND/OR) can be inferred by the order in which the constraints are arranged (currently, we arrange them in ascending order).

This works fine for simple version ranges, like the npm range expression `>=5.1.0 || >=3.10 <4.0`, which is converted to `vers:npm/>=3.10|<4.0|>=5.1.0`. When testing whether a given version, say `3.12.0`, belongs to our range expression, we perform pairwise lookups, i.e., we test if our version belongs to either of the two pairs `(>=3.10 and <4.0)`, `(>=5.1.0)`.

However, this assumption fails for more complex range expressions, such as the npm range expression `>=1.2.3-alpha <1.2.4 || >=1.2.3 <2.0.0`, which essentially translates to any version between `1.2.3` and `2.0.0` including prerelease for base `1.2.3` but should not include prerelease for other bases (e.g., 1.3.0-alpha.1 is not allowed).
Now, univers VersionRange stores this range as `vers:npm/>=1.2.3-alpha|>=1.2.3|<1.2.4|<2.0.0`, and performing pairwise operations on this will yield incorrect results.

A better approach would be to explicitly preserve the information regarding logical operations.

- Use `,` to denote the AND operation.
- Use `|` to denote the OR operation.

This will also make the version expression human-readable and simplify the logic for testing whether a version is present in the version range or not.

In this new design, we will store `>=1.2.3-alpha <1.2.4 || >=1.2.3 <2.0.0` as `vers:npm/>=1.2.3-alpha,<1.2.4|>=1.2.3,<2.0.0`.

This is also the root cause of https://github.com/nexB/univers/issues/118