fix(search): support identifier aliases (cds, cdsrn, aleph, doi)

[TahaKhan998]

Closes #703

This PR simplifies identifier search by introducing aliases (identifier, cds, cdsrn, aleph, doi), allowing queries like cds:12345 instead of metadata.identifiers.identifier:value.

Aliases are mapped via SearchFieldTransformer in invenio.cfg, and tests are added to verify correct query transformation.

[palkerecsenyi]

Looks perfect, just a quick question

[zubeydecivelek]

Looks great 🚀

[sakshamarora1]

Clean 🚀

[kpsherva]

LGTM for the identifiers part! I am happy to merge it. (see there is a minor comment left)
What other fields would you propose to simplify?

[kpsherva]

both cds (legacy) and inspire identifiers' values are integers. How can we ensure that the query will not return both cds and inspire matching records when user searches for cds:12345?

[TahaKhan998]

Yeah, this is actually something I tried to handle earlier with an AND clause to enforce both the scheme and the identifier value.

The idea was that something like cds:12345 should translate to “find an identifier where scheme = cds AND value = 12345”, so we don’t get cross-matches with other identifier types.

However, the issue was in how the transformer builds the query. The AND clause was effectively applied across the whole record instead of within the same identifier entry. So it behaved like:

“record has some identifier with scheme = cds AND record has some identifier with value = 12345”

instead of enforcing both conditions on the same identifier object.

Because of that, a record with cds:263303 and inspire:12345 could still match a query like inspire:263303, since the scheme and value conditions were satisfied by different identifiers.

So the issue wasn’t really with the idea of restricting by scheme, but with how the transformer applies those conditions. Right now the mapping only targets the value, so we don’t yet strictly guarantee scheme-level isolation.