add API for the new uniform neighborhood sampling

[ChuckHastings]

Added an API for the new uniform neighborhood sampling implementation.

Added the API with an experimental tag in its name so it won't break the current python code. Plan is to have the new API replace the existing API during this release.

Plan for this release will be to have the edge weight be an edge index (passed by the calling python code), so the return "index" value will be the edge weight. Down the road we will release this restriction and allow real edge weights.

Addresses part 1 of #2226

[seunghwak]

@ChuckHastings So, in using the wedge weight as the edge index, are you planning to set weight_t to integer type? Or you plan to store integer in floating point format? I guess the latter will be less invasive (assuming there is no resolution issue for a very large number of edges).

[seunghwak]

LGTM.

[ChuckHastings]

@ChuckHastings So, in using the wedge weight as the edge index, are you planning to set weight_t to integer type? Or you plan to store integer in floating point format? I guess the latter will be less invasive (assuming there is no resolution issue for a very large number of edges).

I was imagining I would instantiate graph_t<int32_t, int32_t, int32_t>, graph_t<int32_t, int64_t, int64_t> and graph_t<int64_t, int64_t, int64_t and use them for use in only this algorithm. But if the cost is too great in the implementation - since we do no computation using the weight values for this algorithm - we could use the float for int32 and the double for int64 and everything should work fine. I'll work that out during implementation.

[ChuckHastings]

rerun tests

[ChuckHastings]

rerun tests

[ChuckHastings]

@gpucibot merge