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

[BenWiederhake]

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.)