PrairieMetadata: add data structure for key/values

The key/value pair structure got more complex in PrairieView 5.2. Now
each key can point at either a single string item, or at a table of
values, which can themselves point at sub-tables.

This data structure is intended to facilitate easy management of the
new structure, while still supporting the old structure, too.
PrairieMetadata: use ValueTable as appropriate
PrairieMetadata: parse old-style keys into tables

As of PrairieView 5.2, the key/value pair structure is more
hierarchical, with value tables able to contain sub-tables.

Let's parse the old-style keys in the same way, so that regardless of
which version of PrairieView wrote the data, it can be consumed in the
same way after parsing.
PrairieMetadata: rename field, to avoid ambiguity

We are going to add additional ValueTable fields in other places,
and calling them all "values" gets confusing (and causes IDEs to
emit warnings about variable names shadowing one another).
PrairieMetadata: add a way to parse new key/values

PrairieView 5.2 stores the key/value structure differently: it uses a
sequence of PVStateValue elements with IndexedValue and SubindexedValue
elements underneath. This commit adds the code necessary to parse such
structures into a ValueTable object.
PrairieMetadata: parse PVStateShard at all levels

There are three levels where PVStateShard subtrees appear:

1) PVScan (the top level)
2) Sequence
3) Frame

Let's parse all of them into separate ValueTable objects.
PrairieMetadata: fall back to ancestor ValueTables

If a Frame's ValueTable (i.e., PVStateShard) does not contain
a requested key, search its parent Sequence for the same.

Similarly, if a Sequence's ValueTable is missing the key,
search the top-level PVScan's ValueTable, too.

This behavior is required to support the new "smaller XML file format"
which has been an option since PrairieView 5.0, and the only option
since PrairieView 5.2.