tr: bad error priority between overlong set2 and offset mismatch upper/lower

This is just a minor issue about which error takes precedence.

In particular, the following invocation of tr is invalid for three different reasons:

• The usages of [:upper:] and [:lower:] are misaligned.
• SET2 ends up way too long (expected 256 - 26 = 230, but 256 are provided).
• SET2 has more than one unique character.

It probably doesn't matter too much, but our error-behavior differs from GNU.

$ x230="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
$ echo -n 'hello' | tr -c '[:upper:]' "${x230}[:lower:]"
tr: when translating with complemented character classes,
string2 must map all characters in the domain to one
[$? = 1]
$ echo -n 'hello' | cargo run -q tr -c '[:upper:]' "${x230}[:lower:]"
tr: when translating, every 'upper'/'lower' in set2 must be matched by a 'upper'/'lower' in the same position in set1
[$? = 1]

I believe our error message is actually the better one, so feel free to close this as "WONTFIX". Or do we want to exactly match GNU tr even in error message priority? (In some other tools we do!)

(Found while reviewing #6564.)

Start by reproducing the two shown tr invocations and comparing their diagnostics with GNU tr. The issue names no source file or test; completion requires deciding the intended error precedence and documenting or testing that behavior before making any change.