Do not detect MD5s as UUIDs, and preserve UUID casing for UUID PKs

[nolar]

Comparing MD5s as UUIDs does not work anyway: it improperly slices and then compares the values, since our code always renders UUIDs as abcdabcd-abcd-abcd-abcd-abcdabcdabcd, always dashed and lower-cased, while the actual value stored in MD5 (i.e. string) PKs can be uppercased and typically non-dashed (e.g. ABCDABCDABCDABCDABCDABCDABCDABCD). As a result, all such MD5 PKs go into one pseudo-UUID range, usually the first one (because in ASCII & UTF-8, uppercase is lesser than lowercase letters).

The root cause is that Python's UUID can parse even such values:

In [3]: from hashlib import md5
In [8]: s=md5(b'hello').hexdigest()

In [9]: s
Out[9]: '5d41402abc4b2a76b9719d911017c592'

In [10]: from uuid import uuid4, UUID
In [11]: UUID(s)
Out[11]: UUID('5d41402a-bc4b-2a76-b971-9d911017c592')

This PR excludes MD5s and other UUID-like textual PKs from UUID detection.

As an extra change (separate commits), this PR also preserves the information on how the database presents the UUIDs — either lowercased or uppercased, and renders the actual sliced UUID values accordingly. This does not matter for native UUIDs (stored & compared as numbers), but does matter for UUIDs stored and/or compared as strings (at least from one side of the diff).

[nolar]

FIXED. On a unrelated discussion, this popped up: two sides should be lower-/upper-cased independently based on each side's samples. However, we now slice by PK ranges of one side, and propagate that side to the other one. The casing of the "other" side must be preserved.

[dagadbm]

to unblock if needed but needs proper review