fix(reading): bound how deeply a datatype may nest

[Blackclaws]

Decoding a datatype message is recursive: the message contains its base type inline, and DatatypeMessage.Decode descends into it from six places in DatatypePropertyDescriptions.cs — an array's base type, a compound's members, an enumeration's base type and a variable-length sequence's. Nothing bounded that recursion, and the depth is read from the file.

A file that nests deeply enough therefore exhausts the stack. That is the one decoding failure a caller cannot handle: the runtime terminates the process on StackOverflowException, where every other malformed input raises something catchable, so wrapping H5File.OpenRead in a try/catch is no defence. Around 1500 levels sufficed on my machine, though the exact depth depends on the stack the reader happens to run on. The nesting need not even be invalid — a well-formed chain of variable-length sequences costs 8 bytes per level, so under 16 kB of file is enough.

H5ReadOptions.MaxDatatypeNestingDepth now bounds it, defaulting to 64. That is far above the handful of levels a real datatype composes — a compound of arrays of compounds — and far below where the stack runs out. Exceeding it throws NotSupportedException naming the option, so a file that genuinely nests further can still be read by raising the bound, and a caller reading untrusted files can lower it.

The bound and the current depth are threaded through DatatypeMessage.Decode and the four recursing property decoders, with the check in one place on the way in. The two entry points supply it from context.ReadOptions.

Worth flagging

• H5ReadOptions gains a constructor parameter, so the record's constructor and Deconstruct signatures change. Source-compatible — the parameter is last and optional — but an assembly compiled against the previous version needs recompiling.
• The default is a policy choice. 64 is generous for composed datatypes but it is a cap where there was none, so a file nesting deeper than 64 that previously decoded will now be refused until the option is raised. I could not construct such a file with PureHDF's own writer, and did not find one in the test corpus.
• The limit is deliberately not derived from where the stack actually runs out, since that varies with stack size and build configuration.

Found while investigating the object header message size limit in #179 — one of the corrupt files that bug produced happened to decode into deep nesting — but the two are independent, and this reaches any malformed file rather than anything PureHDF writes.