Use alphanumeric sorting for VisitOrder#createByName

[NebelNidas]

Useful especially for intermediary-like names, so situations like these don't happen:

See the Yarn diff here: FabricMC/yarn@4ec1a6e...NebelNidas:yarn:1.21.1-alphanumeric-sort

[modmuss50]

Some tests would be nice, but considering its an exisitng algorithm I trust it works.

[NebelNidas]

Should I make sorting just always use the alphanumeric comparator? Then we wouldn't break the API, and there isn't much reason not to use it anyway, since performance overhead should be negligible

[liach]

I don't think including an outside comparator implementation under a different license is a good idea: This sort should be done on the intermediary user side as it is not beneficial to any other case.

In addition, the comparator we actuall need is way more simple than this: the implementation would simply be like Comparator.comparing(String::length).thenComparing(Comparator.naturalOrder()).

[sfPlayer1]

I have my own alphanum sorting impl somewhere..

[NebelNidas]

@liach My rationale for reopening this (as discussed on Discord):

• I very much believe MIO's default output should be as human-friendly and intuitively sorted as possible.
• Comparing by length first, as per your suggestion, may work well for obfuscated source names (gives a ProGuard-like order), but for non-obfuscated source names this gives quite suboptimal results.
• Providing a proper default in MIO directly helps for when we add the sorted property via Tiny v2.1, which is going to allow efficient binary searching, and having good first-party sorting raises the chances of consumers using it = less chance of a custom order being used = higher chance that the order used for writing is available at read-time.

The licensing concerns are addressed by switching to an Apache-2.0-licensed algorithm instead, we might even switch to Player's solution when he gets the remaining bugs ironed out.