MDEV-38904 Strings: Fix my_convert infinite loop and latin7 collation

[itzanway]

This PR addresses MDEV-38904, which involves a transitivity violation causing false index corruption in latin7 tables, and a subsequent vulnerability where the server hangs at 100% CPU during string conversion of malformed data.

1. Failsafe Loop Fix: my_convert Infinite Loop (strings/ctype.c)

The Problem: Even in cases of severe table corruption or malformed byte sequences, the server should never hang. The previous implementation of my_convert_using_func and my_convert_fix failed to explicitly force a pointer advancement when the character set's mb_wc function returned a length of 0 (which occurs when reading corrupted byte sequences).
The Fix: Added an explicit from++ advancement when cnvres == 0. This ensures the conversion loop always strictly terminates, replacing the unreadable/malformed bytes with a ? placeholder instead of looping infinitely.

2. Collation Logic Fix: latin7_general_ci (strings/ctype-extra.c)

The Problem:
A transitivity violation existed in the latin7_general_ci collation. In the sort_order_latin7_general_ci array, the hyphen (-, 0x2D) and the space ( , 0x20) were assigned overlapping weights. During MyISAM/Aria index compression, these collisions resulted in circular B-tree pointers, causing CHECK TABLE to falsely report "Key in wrong position" and flagging healthy tables as corrupted.
The Proposed Fix:
Adjusted the sort_order_latin7_general_ci weights to ensure that the space character (Index 32) is uniquely weighted as the minimum printable value, and that the hyphen (Index 45) has a strictly distinct weight to prevent B-tree sorting collisions.

---

I have updated this PR to address the requested housekeeping items:

• Squashed all changes into this single, clean commit.
• Formatted the commit message to strictly comply with CODING_STANDARDS.md.
• Cleaned the patch to ensure there are no space-only/tab-conversion changes.
• Added MTR test cases (mdev_38904.test) to reliably verify the loop termination and CHECK TABLE behavior.

Regarding the Collation Weights (Backwards Compatibility):
I completely understand and agree with your warning. Adjusting the existing weights on latin7_general_ci will break backwards compatibility for on-disk B-tree indexes across existing deployments.

I have left the adjusted logic in this commit solely so you can review the proposed transitivity fix. Moving forward to the final review, how would you prefer to architect this to protect user data? Should we implement these corrected weights under a brand new collation ID/name, or is there a preferred versioning mechanism MariaDB uses for patching existing collations?

Looking forward to your guidance!