Fix three bugs that silently drop or crash on page text extraction

[jrzmurray]

Summary

Three bugs in the property/file-node parsing that either crash outright or silently drop page text, found while extracting a real multi-year notebook with pages authored on both Windows and Mac OneNote clients.

1. PropertyID.type == 0x10 (ArrayOfPropertyValues) is unimplemented (FileNode.py, PropertySet.__init__): it's a bare raise NotImplementedError. Any page using an array-typed property fails to parse at all, and since callers typically catch the exception around a whole-file parse (as the pyonenote CLI/most integrations do), this silently drops all text in that section. Implemented per [MS-ONESTORE] 2.6.9 prtArrayOfPropertyValues: a cProperties count, then (if nonzero) a prid header followed by that many nested PropertySet structures.

2. ObjectDeclaration2LargeRefCountFND has no dispatch branch in FileNode.__init__. Used for objects whose reference count doesn't fit in one byte (larger/more heavily-shared content). Since no branch matches, self.data is never set for such nodes, which:

   • makes their content invisible to get_properties(), and
   • crashes with AttributeError: 'FileNode' object has no attribute 'data' if the node has baseType == 2 (i.e. has children), since the trailing self.children.append(FileNodeList(file, self.document, self.data.ref)) runs unconditionally.

   Also fixed: the two ReadOnlyObjectDeclaration2*RefCountFND branches set self.data but never parse out self.propertySet (unlike the plain ObjectDeclaration2RefCountFND branch does), so their text was likewise invisible even though the node itself didn't crash. OneDocment.get_properties()'s hardcoded single-type filter (['ObjectDeclaration2RefCountFND']) is broadened to include all four declaration node types, with the ReadOnly* variants' body accessed via their .base wrapper.

3. TextExtendedAscii is decoded as UTF-16 instead of latin-1. OneNote for Mac stores plain-text runs under this single-byte-per-character property instead of Windows OneNote's RichEditTextUnicode (UTF-16). Decoding it as UTF-16 either garbles it into CJK-looking noise (even byte count) or throws and falls back to a raw hex dump (odd byte count) -- either way the original text is unrecoverable from get_properties()'s output. This one likely explains why pages/notebooks captured on OneNote for Mac often come back looking empty or garbled with this library.

Testing

No test suite exists in this repo to extend, so I verified against a real notebook backup with a mix of Windows- and Mac-authored sections, before/after this patch (content is private/client data so I can only share aggregate numbers, not excerpts):

Section	Before	After
Section hitting the ArrayOfPropertyValues crash	crashed, 0 chars extracted	~1.17M chars extracted
Another section w/ same issue	crashed, 0 chars extracted	~611K chars extracted
Mac-authored section	~330 bytes (bare page timestamps only, no body text)	~173K chars of real body text extracted
Another Mac-authored section	titles only, no body text	~336K chars of real body text extracted

Happy to add a synthetic .one fixture + test if that's useful for merging -- let me know your preference for how this project handles tests.

Compatibility

No public API changes. PropertySet(file) (single-arg, previously broken/unreachable for the 0x11 array-element branch) now consistently requires the same (file, OIDs, OSIDs, ContextIDs, document) signature used everywhere else it's constructed in this file, matching how PropertySet is actually always instantiated in practice.

[jrzmurray]

Heads up: after opening this, I found that the ArrayOfPropertyValues fix here overlaps with #16 by @ostraconify (open since March 2023), which implements the same property type. While integration-testing #16 I also found two bugs in its implementation (nested array elements were appended to self.rgData individually instead of as one list, which desyncs self.rgData from self.rgPrids for every property after an array-typed one; and the prid header was read unconditionally even when the spec says it must not be present for an empty array). I've opened #30 to finish #16 with proper attribution to @ostraconify and fix both of those.

So there's now duplication between this PR and #30 on the ArrayOfPropertyValues piece specifically. The other two fixes here -- the missing ObjectDeclaration2LargeRefCountFND dispatch branch (and ReadOnly* propertySet loading / get_properties() filter broadening that goes with it), and decoding TextExtendedAscii as latin-1 for OneNote-for-Mac content -- aren't covered by #16, #20, #26, #27, or #28, so those parts of this PR should still stand on their own regardless of what happens with #30.

Also worth noting for review: #20 and #28 both independently propose the same FileNode.data crash-guard fix that's part of this PR too (#28 is the cleanest version, with a regression test). And #26/#27 are unrelated, complementary defensive-parsing fixes. Happy to help however's most useful in sorting out merge order across all of these.