Implements candidate code for pocessing ArrayOfPropertyValues

[ostracon]

Tested on 5ad84c75b4a8825a4ee49fcb2ab895f0a51c9877fc4e50595fa1917ae1daa748 (in VT), which contains this element.

[ostracon]

Added code to handle a few more edge cases found while looking at various files.

[DissectMalware]

Thank you for your PR can you also hare you samples for the edge cases?

[orangeruan128]

Independent reproduction: applying this patch on top of main resolves NotImplementedError: ArrayOfPropertyValues is not implement on a corpus of real-world .one files. The shape used here — cproperties (uint32) followed by a PropertyID whose type is asserted to be 0x11, followed by cproperties PropertySet instances — matches [MS-ONESTORE] 2.6.6 prtArrayOfPropertyValues and successfully parses the files in question.

Two small observations on the diff that may be worth folding in (or doing as a follow-up):

• The companion elif type == 0x11: branch a few lines below still calls PropertySet(file) without OIDs, OSIDs, ContextIDs, document, which trips a TypeError on inputs that exercise the singleton (non-array) variant. Updating that call to PropertySet(file, OIDs, OSIDs, ContextIDs, document) keeps it consistent with the array case implemented here.
• The assert prid.type == 0x11 is technically what the spec requires, but downgrading to a soft warning + break would let parsing recover gracefully on slightly out-of-spec files instead of aborting the whole document.

Either way, this PR fixes a real, reproducible failure on a non-trivial number of files. Combined with #20 (FileNode.data initialization) and #26 (.hex() type safety), the three together cover the most common parser aborts on real-world OneNote backups.