Made the labels in edit relationships tab unique

[alexandrevryghem]

Description

Currently, the relationship type labels are not unique and don't work well when the relationship type is not in the form is{Entity1}Of{Entity2}. This PR ensures they are unique by including the two entity types and the relationship type in the label.

Instructions for Reviewers

List of changes in this PR:

• Changed the way the getRelationshipMessageKey works by always forming the labels in the form: relationships.${currentEntityType}.${relationshipType}.${relatedEntityType} (both entity types are required in order to support the use case from Entities relations with invalid associations shown #1387)
• I mapped all the i18n values from the previous keys to the new keys to avoid breaking the relationship type labels in other languages
• I also changed the duplicate Publication label on the OrgUnit's edit relationship tab to: Organisation Publications & Authored Publications

Guidance for how to test or review this PR:

• Verify that all default keys are correctly translated (I only created translations for the ones defined in dspace/config/entities/relationship-types.xml)

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 yarn lint
• My PR doesn't introduce circular dependencies (verified via yarn 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.