Implement XML Matrix decoding in OpcUaXmlDecoder

[LivingLikeKrillin]

Summary

OpcUaXmlDecoder's four Matrix decode methods (decodeMatrix, decodeEnumMatrix,
and the two decodeStructMatrix overloads) were stubs that returned Matrix.ofNull().
The encoder side (OpcUaXmlEncoder.encode*Matrix) is fully implemented, so a Matrix
encoded to XML produced well-formed output but did not round-trip — the value was
silently lost on decode.

This was raised in #1762, where the maintainer confirmed it was missed during the
1.0 OpcUaXmlEncoder work and gave the go-ahead (pointing to OPC 10000-6 §5.3).

Changes

• decodeMatrix reads the <Dimensions> and <Elements> the encoder writes and
  rebuilds the Matrix with the requested OpcUaDataType.
• decodeEnumMatrix reduces each element to Int32, and decodeStructMatrix decodes
  the self-describing ExtensionObject elements back into their structures (returning
  a Matrix of UaStructuredType) — both mirror OpcUaBinaryDecoder and keep the
  decode→encode round-trip intact.
• Locate the <Dimensions>/<Elements> wrappers by element type, so indented XML
  (e.g. copied from a UANodeSet) also decodes.
• Reject malformed Matrix XML with Bad_DecodingError instead of building an invalid
  Matrix, per OPC 10000-6 §5.3: dimensions whose product does not match the element
  count, non-positive dimensions, builtin elements whose XML tag name is not the
  requested type name, and (for decodeStructMatrix) ExtensionObjects that decode to
  a different structure type than the requested dataTypeId — the last resolves the
  codec for dataTypeId and validates against it, mirroring decodeStructArray.
• Guard Matrix.toString() against the null-Matrix NullPointerException noted in
  the issue (ArrayUtil.getType on a null flatArray).

Tests

• OpcUaXmlDecoderMatrixTest: round-trips the same MatrixArguments fixtures the
  encoder tests use across the builtin, enumerated, and structured types; asserts that
  struct matrices decode back to UaStructuredType; indented-XML and null-Matrix
  decode cases; plus the validation cases for malformed XML (mismatched/non-positive
  dimensions, wrong element name, unexpected struct type).
• MatrixTest: toString() on a null Matrix no longer throws.

Fixes #1762

---

Developed with AI assistance (Anthropic Claude Opus 4.8); the human contributor
reviewed, verified, and tested all changes.

[kevinherron]

I pushed a small set of failing test cases in e86f87017 that capture behavior the XML Matrix decoder should handle before this lands. The tests document expected decoder behavior; the implementation still needs to be updated to satisfy them.

1. Dimension/product validation

   OPC 10000-6 section 5.3.1.17 says all Matrix dimensions must be specified and greater than zero, and that inconsistent dimensions must cause the decoder to stop and raise Bad_DecodingError:

   https://reference.opcfoundation.org/specs/OPC-10000-6/5.3

   The added test uses dimensions [2, 2] with only one element. That should fail because a 2x2 Matrix requires exactly 4 flattened elements.

2. Non-positive dimensions

   The same section says Matrix dimensions must be greater than zero. The added test uses a zero dimension and expects the decoder to reject it instead of producing a malformed Matrix.

3. Element XML type-name validation

   OPC 10000-6 section 5.3.4 says array element names shall be the type name, and section 5.3.1.17 defines Matrix <Elements> as the flattened array contents.

   If the caller requests an Int32 Matrix, the entries under <Elements> should be <Int32> elements. The added test checks that an Int32 Matrix rejects a <String> element.

4. Struct Matrix expected type

   decodeStructMatrix("Test", XVType.TYPE_ID) should not silently accept ExtensionObjects whose bodies decode to a different structure type, such as ThreeDVector.

   XML ExtensionObjects are self-describing, but for a non-subtyped struct field the dataTypeId argument is still the declared/expected structure type for that field. The added test encodes a ThreeDVector Matrix and tries to decode it as XVType, expecting the decoder to reject it.

[LivingLikeKrillin]

Thanks, these probes were helpful — they map cleanly onto four validation gaps. I've pushed a follow-up commit (bc0d22885) that implements all four; the test cases you added now pass, and the existing round-trip tests stay green.

• Dimension/product — after reading <Dimensions> and <Elements>, the decoder checks that the product of the dimensions equals the number of decoded elements and raises Bad_DecodingError otherwise (decodeMatrix and decodeEnumMatrix share the check).
• Non-positive dimensions — each dimension is validated as > 0 while parsing <Dimensions>.
• Element type name — decodeMatrix now requires each <Elements> child's tag name to equal the requested type name, so an Int32 Matrix rejects a <String> element instead of parsing its text as an Int32.
• Struct Matrix type — you're right that the declared dataTypeId should be enforced. I'd originally left it out, reasoning the ExtensionObjects are self-describing, but rejecting an unexpected type is the safer contract for a non-subtyped field. decodeStructMatrix now resolves the codec for dataTypeId and validates each decoded structure against codec.getType(), mirroring decodeStructArray (the ExpandedNodeId overload resolves and throws on an unregistered namespace, as the binary decoder does).

I've also dropped the now-inaccurate "dataTypeId is not needed" note from the PR description.