Summary of important user-visible changes for datatypes 1.3.2:
--------------------------------------------------------------

 This release fixes a `categorical` defect that silently dropped array
 elements, and widens `keyHash` and `keyMatch` to the last three types MATLAB
 keys that this package did not.  Nothing that worked before behaves
 differently, and **no hash code changes**: codes stored by 1.3.1 remain
 valid.

 ** Concatenating or comparing a `categorical` array with a non-scalar
    `missing` no longer loses elements.  The missing operand was sized from a
    fresh scalar `missing` rather than from itself, so it collapsed to 1-by-1:
    `[categorical(NaN(1,3)), repmat(missing,1,3)]` returned a 1-by-4 array
    instead of 1-by-6, dropping three elements with no error, and
    `isequaln (categorical(NaN(1,3)), repmat(missing,1,3))` was false.  Both
    disagreed with the same operation in the other operand order, which was
    already correct.  `cat`, `isequal` and `isequaln` are all affected.

 ** `keyHash` accepts `struct`, `cell` and `function_handle`, and `keyMatch`
    accepts them with it, closing the last parity gap in `keyMatch`.
    `keyMatch` itself is unchanged: it asks `keyHash` whether a value can be
    hashed rather than keeping a list of its own, so widening one widened the
    other.

 ** A `cell` array is keyed on its elements, each hashed in turn, so it may
    hold any type `keyHash` accepts, nested to any depth.  Shape and nesting
    are part of the key, so `{1, 2}` and `{1; 2}` are different keys, as are
    `{{1}}` and `{1}`.  An element whose class has its own `keyHash`
    method reaches it, so a cell holding a `datetime` or a `categorical` is
    keyed correctly.

 ** A `struct` is keyed on its field names and their values.  The order in
    which its fields were created is **not** part of the key, so two structs
    differing only in field order are the same key -- matching R2024a, and
    matching `isequaln`, which already ignored field order.  The class of a
    value *inside* a struct or a cell **is** part of the key, so
    `keyMatch ({1}, {int8 (1)})` is false, as it is for `1` and
    `int8 (1)` at the top level.

 ** A function handle is keyed on its text alone.  Two named handles for the
    same function are one key.  Two anonymous handles never match, even when
    written identically, so an anonymous handle cannot be found again as a
    key; what a handle captures is therefore not part of its hash, which is
    also how R2024a hashes them.

 ** `keyHash` and `keyMatch` name the value that cannot be hashed rather than
    the container holding it.  With `cell` and `struct` now keys in their own
    right, reporting `'cell'` for `keyMatch ({table(1)}, {1})` pointed at
    the wrong type; both now report `'table'`.  `keyHash` names the class it
    rejected instead of saying only that some input was unsupported, and
    `keyMatch` passes that message through instead of restating it from its
    own operand.

 ** Hash codes for every previously supported type are now pinned by tests
    carrying the literal values measured from 1.3.1.  Codes are a published
    interface -- this package produces the same code across workers and
    sessions, which MATLAB's randomly seeded `keyHash` does not -- so a code
    changing is a breaking change, and these tests exist so that it cannot
    happen by accident.
