fix: preserve list meanings

[daniel-sanche]

Currently, the library only keeps track of the meaning field of sub-elements of array_values it sees. We also need it to keep track of the meaning of the array itself

This PR addresses this by returning a tuple of (root_meaning, sub_meaning_list) instead of just the sub_meaning_list in _get_meaning(), and using the tuple to populate the fields properly in _set_pb_meaning_from_entity()

[NickChittle]

I'm curious, why wouldn't we just return a tuple of (None, []), instead of transforming the return type here to just a single None?

(To me it would be simpler to have a guaranteed format for List, and a guaranteed format for non-lists, or maybe this saves some RAM?)

[daniel-sanche]

In case it's not clear: the reason for this transformation is to flatten giant lists of [None, None, None, ...], so we don't have to iterate over the whole thing again later, when there are no meanings present (which is probably the most common situation)

You're right that we could return an empty list instead of None here to signal that there are no meanings present. But it's a trade-off. That would buy us type consistency, but then we'd lose the property that the sub-meaning list is always be the same size as the original array. We'd need to remember to do size comparisons before iterating, so we don't really win anything from that change. And size mismatches wouldn't be flagged by type checkers like missing None checks, so those bugs would be harder to notice.

TL;DR: This is a special case in our processing logic, and it's usually safer to use None to signal special cases, instead of returning lists with unpredictable sizes