Stabilize ModuleDependency descriptions

[DragonFSKY]

Fixes #1630.

This makes ModuleDependency#getDescription() render its underlying class dependencies in their natural Dependency order, instead of relying on the iteration order of the backing set. The collected dependencies are unchanged; only the textual report output is stabilized.

A regression test verifies that the rendered description follows the same sorted dependency order.

Tested with:

./gradlew :archunit:test --tests com.tngtech.archunit.library.modules.ModuleDependencyTest

[hankem]

Thank you so much for your contribution, and first of all sorry for the late feedback!

The only thing I'd like to test is how much sorting affects the performance, but other than that, I have no concerns that we can integrate your fix soon.

[DragonFSKY]

Thanks for taking a look, and no worries about the timing! I fixed the DCO issue and normalized both commits to the same GitHub identity/sign-off.

I also ran a targeted local benchmark on JDK 25 using real ModuleDependency instances built from ArchUnit classes. It compared the previous unsorted description rendering with the sorted rendering in this PR; the figures below are medians from seven alternating rounds:

Class dependencies	Unsorted	Sorted	Added time
81	17.3 us	22.0 us	4.7 us
926	126.4 us	455.7 us	329.3 us
5,449	1.35 ms	3.41 ms	2.05 ms

So the relative cost is visible for large dependency sets, but the absolute overhead stayed around 2 ms even for the largest real module dependency in this sample, and it is limited to the getDescription/reporting path. I hope this helps with the performance assessment.