What changes were proposed in this pull request?

An initial and top level structures for the future PropertyGraphFrame module.

Let's imagine we have a property graph that represent the graph of legal entities for the needs of AML.

In that case our vertices can be:

• Legal entity
• Persons

And edges can be:

• One entity pay to another entity -- bank transaction, a directed weighted edge with weigh eq to amount
• One entity pay to a person -- the same, but vertex types are different
• A person is a member of the entity board or work for an entity -- undirected edge without weight

The core idea is relying on three classes:

• PropertyGraphFrame
• EdgePropertyGroup
• VertexPropertyGroup

Each property group contains it's own data as DataFrame and metadata.

VertexPropertyGroup contains data, related to a group of vertices. For example, for entities it can some metadata, like name, assets, legal form, history of AML violations, etc. For persons it may something else, like name, surname.

EdgePropertyGroup for example, for an edge group entity-pay-entity is a weighted edge group with directed edges. And for a case two entities share one board member (person) it is undirected and unweighted edge.

PropertyGraphFrame is just a sequence of edge and vertex groups with an ability to get a GraphFrame object and call algos like clustering, shortest pathes, etc.

Why are the changes needed?

1. At the moment GraphFrame API is very low-level. It is really hard to realize where edges are directed, where edges are undirected. How to construct it, etc. It is nice for library devs, but it may be really hard to work with it for end users like analysts.
2. We cannot support fully OpenCypher just because GraphFrame does not have any properties. With a PropertyGraph abstraction we are open to add a support of the OpenCypher / Gremlin
3. Users can just take multiple data tables, pass it to the PropertyGraph and be happy, instead of doing low-level hacking with creation of edges/vertices, avoiding collisions, etc.

Overall: #602, #565 + some others.

IMPORTANT
Like Spark structures are based on Parquet, I mostly base the proposed structure on Apache GraphAr (incubating) as the only known to me "open-table" format for property graphs!

DISCLAIMER
At the same time, I'm PPMC in GraphAr and there is a potential conflict of interests!

I do not want to write more code before discussing the overall concept and idea. When we are done, I will continue the work by providing additional methods to the API.