Order mappings on concept page first by source vocabulary, then by label

[osma]

Reasons for creating this PR

Cypress tests for the mappings on the concept page were failing, because the two mappings on the example page to "musicology" from Wikidata and "Musicology" from LCSH were not in the expected order. It turned out that the order of mappings depended on the labels only and wasn't stable in a case like this were the labels are the same (case insensitive).

This PR causes the mappings on the concept page (of each type) to be displayed in a consistent order: first by source vocabulary, then by label. This is implemented on the backend side, so that the data returned by the mappings REST API method is sorted. (An alternative approach would have been to do the sorting in the frontend only.)

Result can be seen e.g. on the YSO concept page for "musicology":

Note that the closeMatch mappings are ordered by vocabulary (LCSH < Wikidata) and likewise the exactMatch mappings are now ordered by vocabulary (Allärs < KOKO < YSA). Before this PR, the order could be different as it was based only on the labels (e.g. music research < musiikintutkimus < musikforskning) and could be arbitrary when labels are the same (musicology vs Musicology).

Link to relevant issue(s), if any

• part of Epic: Concept Page #1484

Description of the changes in this PR

• add a getSortKey method to the classes ConceptPropertyValue, ConceptPropertyValueLiteral and ConceptMappingPropertyValue (for the two former, based on label only; for the mappings, based first on vocabulary name, then by label)
• use the getSortKey method when sorting property values in ConceptProperty.sortValues()
• add PHPUnit tests for the getSortKey methods
• adjust the Cypress test for the concept page mappings so that it matches the new order of mapping values

Known problems or uncertainties in this PR

n/a

Checklist

• phpUnit tests pass locally with my changes
• I have added tests that show that the new code works, or tests are not relevant for this PR (e.g. only HTML/CSS changes)
• The PR doesn't reduce accessibility of the front-end code (e.g. tab focus, scaling to different resolutions, use of .sr-only class, color contrast)
• The PR doesn't introduce unintended code changes (e.g. empty lines or useless reindentation)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.58%. Comparing base (4921604) to head (ed30a50).

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #1601      +/-   ##
============================================
+ Coverage     70.54%   70.58%   +0.04%     
- Complexity     1644     1647       +3     
============================================
  Files            32       32              
  Lines          4315     4321       +6     
============================================
+ Hits           3044     3050       +6     
  Misses         1271     1271              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarCloud

[joelit]

LGTM