Add ValueEquality.contentEquals / contentHashCode to org.dexpace.sdk.core.util
for value types that hold array-typed fields. java.util.Objects.equals compares
arrays by identity, so structurally-equal ByteArray (or any array) fields are
wrongly reported unequal; these helpers compare by content instead.

Both helpers handle primitive arrays, object arrays, nulls, and arbitrarily-deep
nested / multi-dimensional arrays (via Arrays.deepEquals / deepHashCode), while
falling back to ordinary equals/hashCode for non-array values. The two methods
are mutually consistent: content-equal values always share a content hash.

…semantics

contentEquals reimplemented java.util.Objects.deepEquals branch for branch, so delegate to it directly instead. Document that array comparison follows Arrays.equals/Double.equals semantics rather than ==: NaN compares equal and 0.0 != -0.0, for both primitive and boxed arrays. Note that contentHashCode mirrors Arrays.deepHashCode by hand and is kept in lockstep with contentEquals.

Add tests for NaN and signed zero across primitive and boxed float/double arrays, plus nested arrays, mixed elements, and non-canonical NaN bit patterns.

… ValueEquality

Expand the ValueEquality KDoc to answer the three questions a reader is most
likely to have about it:

- Why it is public with no in-tree caller: it is a deliberate, forward-looking
  primitive that hand-written (or later generated) value types target for their
  array-typed fields.
- Why contentEquals is a thin wrapper over Objects.deepEquals: to pair
  symmetrically with contentHashCode, for which the JDK offers no
  Objects.deepHashCode counterpart, giving callers one contract-paired API.
- That Kotlin unsigned arrays (UByteArray, etc.) are not recognized as arrays
  and fall through to identity-based equals/hashCode, with the asXxxArray()
  workaround for content semantics.

Doc-only; no signature or behavior change (apiCheck unchanged).