Fix for "MyDSpace status facets display incorrect (named resource) labels after selection"

[VictorDuranEscire]

Hi @tdonohue, I'am @jtimal partner, I like to share this PR with you.

References

• Fixes MyDSpace status facets display incorrect (named resource) labels after selection #3975

---

• Requires Set configuration to determine a label in a filter applied on facets DSpace#10667

Description

From the frontend, as an immediate measure, add translations according to the value generated by the filter applied.
In the backend service we implemented a way to add a label for each filter applied in the search.

Instructions for Reviewers

To reproduce

1. Log in as the administrator or any other user with a busy workspace
2. Expand the Status left-hand facet and select Archived

List of changes in this PR:

1. I added default translations for the status filter to prevent the selected filter from displaying incorrectly.

2. Added a setting in discovery.cfg to define a label for each selected filter.

3. Add a setting to identify which filters to add their labels

4. Add a validation to validate if a filter is within the above settings and generate its label dynamically.

Checklist

• My PR is created against the main branch of code (unless it is a backport or is fixing an issue specific to an older branch).
• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
• My PR passes ESLint validation using npm run lint
• My PR doesn't introduce circular dependencies (verified via npm run check-circ-deps)
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• My PR aligns with Accessibility guidelines if it makes changes to the user interface.
• My PR uses i18n (internationalization) keys instead of hardcoded English text, to allow for translations.
• My PR includes details on how to test it. I've provided clear instructions to reviewers on how to successfully test this fix or feature.
• If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
• If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
• If my PR fixes an issue ticket, I've linked them together.