ISO-19115-3 URN `metadataIdentifier` modified when converted with xsl-view

**Describe the bug**

Conversion from ISO-19115-3 to "xsl-view" modifies URN `metadataIdentifier`s. The "urn:..." `codeSpace` generates a "urn:.../..." identifier in the output.

Example record:

[Original XML](https://sextant.ifremer.fr/geonetwork/srv/api/records/0a048a62-2cc7-40e2-931f-2e37cfe4132a/formatters/xml):
```

0a048a62-2cc7-40e2-931f-2e37cfe4132a


urn:uuid

```

[xsl-view output](https://sextant.ifremer.fr/geonetwork/srv/api/records/0a048a62-2cc7-40e2-931f-2e37cfe4132a/formatters/xsl-view):
```

Métadonnées

Identifiant de la fiche

urn:uuid/0a048a62-2cc7-40e2-931f-2e37cfe4132a

```

**Expected behavior**

URN identifier should use the correct separator according to [RFC-4122](https://datatracker.ietf.org/doc/html/rfc4122#section-3), i.e. `:`.

**Cause**

The [xsl-view](https://github.com/geonetwork/core-geonetwork/blob/main/schemas/iso19115-3.2018/src/main/plugin/iso19115-3.2018/formatter/xsl-view/view.xsl#L903) doesn't handle the special case of URN like other formatters.

**Notes**

Some ISO-19115-3 templates set `codeSpace` to "urn:uuid" by default, so this is likely to affect most ISO-10115-3 catalogs.

Related but not the same as https://github.com/geonetwork/core-geonetwork/issues/9170. I don't have enough knowledge of GeoNetwork to think of all the possible cases where this bug might lurk, nor would I know how to reliably search for it -- besides searching for "codeSpace" which returns quite a lot of hits, and may not catch cases with intermediate variables. This does look like something that would need a more thorough approach, though.

Start at schemas/iso19115-3.2018/src/main/plugin/iso19115-3.2018/formatter/xsl-view/view.xsl around line 903 and compare how other formatters handle URN codeSpace values. Reproduce the conversion with the linked ISO-19115-3 record and verify that the xsl-view output preserves the RFC-4122 colon separator in metadataIdentifier values.

Written by the indexing model from the issue text.