Deserializer fails for Numbers in OrderedItem value entries

[astos-marcb]

Certain JSON data for OrderedItem#v is represented as Number in integration tests and ZIP files created by the Comet-IME.

The WebService uses Strings for representing the identical cdp4common.dto.ArrayParameterType#dimension data.
http://<RDL> -> {"k":1234,"v":"1"}
zipfile/<RDL> -> {"k":1234,"v":1}

The current CDP4-SDKJ implementation always assumes it to be a String and (very silently) errors out when reading ZIP files.
https://github.com/RHEAGROUP/COMET-SDKJ-Community-Edition/blob/2945b89c39d2b94f04bb134e5b8115c814dec281/cdp4jsonserializer/src/main/java/cdp4jsonserializer/deserializers/OrderedItemDeserializer.java#L50

The same OrderedItem#v is required to represent a UUID in cdp4common.dto.CompoundParameterType#component.
Converting to String with toText() instead of textValue() seems to be a working hot-fix (same DTO type as for WebServices replies).
Respective serializer always converts to String value (is this conforming to ECSS-E-TM-10-25 Annex C?).

Alternatives to preserve Number trait:

• distinct element types for Array#dimension and Compound#component with v as Number/Long and UUID, or
• the serializer/deserializer must check if the entity is a Number and is/can be represented verbatim in JSON.

The 2nd alternative might be the cleanest approach and is likely the same behavior as in IME/.Net implementation.
For consistency a change to WebService replies might (then) be appropriate.