Refactor discovery.xml to reduce duplication using Spring parent beans and reusable lists

[alijaber-atmire]

Is your feature request related to a problem? Please describe.

dspace/config/spring/api/discovery.xml (~4,200 lines on main) contains a large amount
of duplicated configuration. Most DiscoveryConfiguration beans (the entity configs such
as publication, dataset, person, project, orgUnit, journal*, their
*Relationships variants, and the workspace/workflow/supervision family) copy/paste the
same properties — searchSortConfiguration, recentSubmissionConfiguration,
hitHighlightingConfiguration, moreLikeThisConfiguration, defaultRpp,
spellCheckEnabled, and large sidebarFacets / searchFilters lists — over and over,
with only small differences between beans.

This causes real maintenance problems:

• Hard to see what is actually different between two configurations, because each bean
  restates the full set of properties instead of just its deltas.
• Error-prone to change. When a shared default changes (e.g. a new facet/filter, or a
  new hit-highlight field), every duplicated bean must be edited by hand, and it is easy to
  miss one or introduce inconsistencies.
• Reviews are noisy. Small behavioral changes are buried in hundreds of lines of
  repeated boilerplate.

Describe the solution you'd like

Refactor discovery.xml to use Spring's existing inheritance/merge mechanics, so each bean
only declares what is genuinely different from its parent:

• parent="X" — a child bean inherits all of X's <property> entries and overrides
  only the ones it redefines. (Already used by communityConfiguration /
  collectionConfiguration today; extend the same pattern.)
• <list merge="true"> — append a few extra entries onto an inherited list instead of
  restating the whole list (e.g. administrativeView, workflowConfiguration,
  supervisionConfiguration are "the parent list plus a couple of extras").

Proposed hierarchy:

• Entity configs (publication, person, project, orgUnit, journal*,
  personOrOrgunit, openaireFundingAgency, geospatialConfiguration, dataset) →
  parent="defaultConfiguration"; dataset → parent="publication".
• Each *Relationships bean → parent="<base entity>", overriding only id,
  defaultFilterQueries, and any genuinely different relation filters.
• defaultRelationshipsConfiguration, unDiscoverableItems, administrativeView →
  parent="defaultConfiguration".
• Workspace/workflow/supervision family chained off workspaceConfiguration.

The result is significantly smaller and easier to maintain (in a working branch this took
the file from ~4,187 to ~3,298 lines, ~21% smaller), and inline comments document, per
bean, what is inherited and what is overridden.

Behavior preservation: the change is intended to be behavior-neutral apart from a small
set of explicitly-documented enrichments (entities inheriting defaultConfiguration's
hitHighlighting / moreLikeThis; administrativeView inheriting the full default facet
set so admins see every filter the public view supports). Beans whose searchFilters do
not contain searchFilterSubject override tagCloudFacetConfiguration to an empty bean so
they continue to pass DiscoveryConfiguration.afterPropertiesSet() validation
(sidebar/tag-cloud facets must be a subset of search filters).

[alijaber-atmire]

Can i please be assigned to this issue please?