Introduce a default ascending lexicographical sorting order within exported and shown entities based on their persistent identifier

[Steffengreiner]

Description

Introduce Sorting of Samples, Measurements and Raw Data via an Ascending sort of the SampleId and MeasurementIds within the UI grids and the downloaded files (Excel Templates and URL Link List).
This PR introduces a natural order comparator for measurementId and Sample Ids to account for the issue of the default natural order comparator (01, 10, 02, 03...).

Issue and Traceability

Linked Task Issue

#1410
#1409

Justification (if applicable)

This issue is constantly referenced in internal stakeholder discussions. It's currently a lot of manual overhead to get a clean overview of the measurements samples and raw data.
Manual sorting of the downloaded Entitites and within the UI takes time and is deleted once the user switches the view.
Since there is currently no sorting mechanism applied, the easiest solution is to start a default sorting and adapt it if the need changes.

Changes Summary

Modified Areas

• [x ] Application layer (application/ services, use cases)
• [x ] UI / Views (views/ components, Vaadin routes)

Behavioral Changes

• Yes, behavior changes: The current non-sensical and non-harmonized sorting is replaced with an internally coherent sorting structure based on the persistent identifiers of the specific entitites.

Pre-Submission Checklist

• Issue Linked: PR references a Task issue (see "Linked Task Issue" section above)
• **Requirements Listed: Requirements are documented within the linked Tasks
• **Other:

[sonarqubecloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)
7.8% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[KochTobi]

I like that you added tests! Please add some tests for the API of the compare method.

Compares its two arguments for order. Returns a negative integer, zero, or a positive integer as the first argument is less than, equal to, or greater than the second.
The implementor must ensure that signum(compare(x, y)) == -signum(compare(y, x)) for all x and y. (This implies that compare(x, y) must throw an exception if and only if compare(y, x) throws an exception.)
The implementor must also ensure that the relation is transitive: ((compare(x, y)>0) && (compare(y, z)>0)) implies compare(x, z)>0.
Finally, the implementor must ensure that compare(x, y)==0 implies that signum(compare(x, z))==signum(compare(y, z)) for all z.

[KochTobi]

Context: @Steffengreiner and I discussed the increased weight of the identifiers. We agreed that some sorting is necessary for now.

[KochTobi]

Amazing