feat(c++): supprt for multi-property data

### Describe the enhancement requested

As [TinkerPop](https://lists.apache.org/thread/qyg9mtllq92xng9zsnvhmlqvowny45vc) hopes that GraphAr can be compatible with multi-property data, the specific descriptions are as follows
```
a multi-property is a bit like storing the values in a list for a
single key, but a multi-property has some particularities to it:
gremlin> g.addV().property('name',['alice','bob'])
==>v[0]
gremlin> g.addV().property(list,'name','craig').property(list,'name','dave')
==>v[2]
gremlin> g.V(0l).properties()
==>vp[name->[alice, bob]]
gremlin> g.V(2l).properties()
==>vp[name->craig]
==>vp[name->dave]

in the above example, the 0 vertex stores a alice and bob as a list while
the 2 vertex stores craig and dave as a multi-property. you can see that
TinkerPop treats the latter as two separate properties which leads to other
differences:

gremlin> g.V().has('name','alice')
gremlin> g.V().has('name','dave')
==>v[2]

In the previous example, alice can't be found because "name" has a List
object to match on for vertex 0. But we can find dave because vertex 2 used
a multi-property which stores it as a string on a individual property.

This may all be Gremlin semantics that i'm describing and might not have
any impact on how you choose to implement the ability to model
"multi-properties" for GraphAR, but I thought i'd clarify their behavior a
bit in case that helped.
```

### Component(s)

C++

The issue names the C++ component but no repository files, tests, or entry points. Start by comparing the TinkerPop multi-property examples with GraphAr's current property model, then define the expected representation and acceptance tests before implementation.

Written by the indexing model from the issue text.