Update PLC, C, (and C++?) APIs to better accommodate python MG graph creation use cases

[rlratzel]

There are three separate requests here. I can break these up into three separate issues if that's better:

Do not require num_edges

The python/dask code currently has to compute/persist the dask_cudf dataframe in order to compute the total number of edges the PLC API requires for creating a graph. This should not be necessary since each array already has the size known internally. Not requiring num_edges would eliminate the need to do the somewhat expensive dask compute/persist call.

NOTE: adding this feature is related to the fix done for this issue

Allow multiple src/dst arrays

In order to ease the burden on the cugraph dask/python code for handling dask_cudf input with multiple partitions per worker, the PLC, C, and possibly C++ APIs could accept multiple src and dst vertex arrays. This would allow the dask/python layer to pass the src/dst arrays from each partition as-is, instead of combining each partition's arrays in python in order to pass them as a single src and single dst array to PLC/C.

Implement a "move" option to transfer array ownership

Another improvement could be to allow the PLC/C/C++ layers to own the src/dst arrays currently maintained in python. This would allow PLC/C/C++ modify and delete the incoming arrays as needed, instead of requiring a copy step to preserve the arrays owned by the user/python layer. This could be a new option, possibly called "move" which would default to False (the current behavior).

[rlratzel]

cc @VibhuJawa @jnke2016