Some documentation about `NameList`'s `Unknown` section

[Gudf]

NameLists can be thought of as dictionaries/associative arrays of resource name to resource properties.
The Unknown section, along with the Names are used to associate a resource name to the resource's data.
Specifically, Unknown::UnknownHeader::unknown and Unknown::unknown are a representation of a Patricia trie/binary prefix tree (though it uses suffixes instead of prefixes here) used to accelerate the lookup of a name and retrieve the resource's index.

Unknown::UnknownHeader::subheader_size: this seems to be the offset within the NameList of the serialized tree (a.k.a of Unknown::UnknownHeader::unknown).

Unknown::UnknownHeader::unknown_size: Offset within the NameList of the data section (a.k.a of element_size).

Unknown::UnknownHeader::unknown and Unknown::unknown: the serialized tree, where each node is comprised of 4 u8s as follows:

• bitIndex: the index of a bit in the looked-up Name
• leftChild: The index of the left child
• rightChild: The index of the right child
• resourceIndex: The index of the resource associated with this node

Bit index x in the string corresponds to the bit at index x mod 8 within the byte at index floor(x / 8). Note that the bits in each byte are considered in little-endian order, that is to say bit index 0 within a byte is the least significant bit, index 7 is the most significant bit. (This means the bit can be retrieved with name[x / 8] & (1 << (x % 8)).)

The first node is presumably always 0x7F, 1, 0, 0, I'm not sure what exactly is its purpose since names are in ASCII so bit 0x7F (decimal 127) is always 0... I suspect it might have been an artifact of the encoding process?

To lookup a name, you traverse the tree by choosing either the left subtree or the right subtree depending on the value of the bit at the current node's bitIndex: left subtree if 0, right subtree if 1. Typically, you would stop once you reach a leaf, which in this case corresponds to reaching a node with an index lower than or equal to that of the previous node. At this point, the looked-up name can be compared directly to the name at index resourceIndex.

The rest is, as far as I can tell, as previously documented, though I would mention that the data section includes element_size and data_section_size for the purpose of data_section_size.

Feel free to say if you'd like me to submit a PR, I simply opted for opening an issue instead because I didn't want to submit a PR with potentially inconsistent formatting wrt the rest of the document.