Make API uniform

[eddieschoute]

What is the expected enhancement?

Currently, many methods require prefixing the name with the type of the graph (i.e. digraph_). Would it be possible to dispatch the right method based on the type of the graph automatically? This arose in a discussion on a prior PR (Qiskit/qiskit#5471 (comment)).

One pythonic way to implement this would be to switch on the type, if implementing this in Rust is a problem. Then the right Rust method may be called by the Python code.

[mtreinish]

I think that using python would be the easier path forward here. I've tried to do this on the rust side several ways and the issue I have is that python binding macros #[pyfunction] which generate the functions which wraps the retworkx functions and actually passes the objects from python aren't able to tell us what traits the python object it passes to the rust definitions has implemented, just that it implements FromPyObject so we get a compiler type error (that's pretty cryptic because it originates in the expanded macro generated function). It'll be easier to just do something like:

def dfs_edges(self, graph, source=None):
    """Get edge list in depth first order

    :param (PyGraph|PyDiGraph|PyDAG) graph: The graph to get the DFS edge list from
    :param int source: An optional node index to use as the starting node
        for the depth-first search. The edge list will only return edges in
        the components reachable from this index. If this is not specified
        then a source will be chosen arbitrarly and repeated until all
        components of the graph are searched.
    :returns: A list of edges as a tuple of the form ``(source, target)`` in
        depth-first order
    :rtype: EdgeList
    """
    if isinstance(graph, PyGraph):
       graph_dfs_edges(graph, source)
    else:
       digraph_dfs_edges(graph, source)

in the main package __init__: https://github.com/Qiskit/retworkx/blob/master/retworkx/__init__.py
and just do that for every split function in the api. Although, given the number of these there will be though (since it's most of the algorithm functions, all the generators, and all the random graph functions) it might make more sense to create a new ufunc.py or something like that and do this in there and then just re-export all of them from the package root.