Guarantee a stable ordering with build metadata

[rbarrois]

Sorting any permutation of Version objects should always yield the same
result, even if those hold some build metadata.

To that end, the "precedence_key" is now used exclusively for sorting;
direct comparisons between Version objects still ignores the "build"
metadata, using a different precedence key.

For performance improvements, both precedence keys are cached.

Closes: #132

[keshav-space]

Something isn't adding up ;)

Python 3.9.12 (main, Mar 26 2022, 15:51:15)
[Clang 13.1.6 (clang-1316.0.21.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import semantic_version
>>> semantic_version.__version__
'2.10.0'
>>> v1 = semantic_version.Version("2.0.12+123")
>>> v2 = semantic_version.Version("2.0.12+1")
>>> v3 = semantic_version.Version("2.0.12+321")
>>> v4 = semantic_version.Version("2.0.12+22")
>>> sorted([v1,v2,v3,v4])
[Version('2.0.12+123'), Version('2.0.12+1'), Version('2.0.12+321'), Version('2.0.12+22')]
>>> sorted([v2,v1,v3,v4])
[Version('2.0.12+1'), Version('2.0.12+123'), Version('2.0.12+321'), Version('2.0.12+22')]
>>> sorted([v3,v2,v1,v4])
[Version('2.0.12+321'), Version('2.0.12+1'), Version('2.0.12+123'), Version('2.0.12+22')]
>>> sorted([v4,v2,v1,v3])
[Version('2.0.12+22'), Version('2.0.12+1'), Version('2.0.12+123'), Version('2.0.12+321')]

[rbarrois]

@keshav-space Use sorted(..., key=lambda v: v.precedence_key) ;)

[keshav-space]

Is there a specific reason for not having this as a default behavior?

[rbarrois]

Yes: it would break the existing documented behaviour (and several tests from the test suite), requiring a major version bump!