Add edge_indices methods to graph objects

[mtreinish]

This commit adds a new method to the PyDiGraph (and PyDAG) and PyGraph
classes, node_indices, which returns a list of a edge indices for all
edges in the graph.

[coveralls]

Pull Request Test Coverage Report for Build 864293999

• 68 of 74 (91.89%) changed or added relevant lines in 4 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.05%) to 96.803%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/iterators.rs	57	63	90.48%

Totals
Change from base Build 864293350:	-0.05%
Covered Lines:	7660
Relevant Lines:	7913

---

💛 - Coveralls

[ajavadia]

A few questions::

• Are edge indices static identifiers for unique edges? What happens if I remove an edge, do others maintain their edge indices or get re-indexed? (I think this should be documented)

• Are edge indices assigned in the order the edges were created? If so then I think they are not properties of the graph, i.e. two identical graphs could have different edge indices if they were created in different orders.

[mtreinish]

A few questions::

* Are edge indices static identifiers for unique edges? What happens if I remove an edge, do others maintain their edge indices or get re-indexed? (I think this should be documented)

Yes, they're stable unique identifiers for each edge in the graph. If an edge is removed in the middle the other indices don't change. I agree this should be documented and I thought that it was in the class docstring for PyDiGraph and PyGraph but looking there now it only mentions the integer index and not that it's stable. The retworkx for networkx users doc does mention this though: https://retworkx.readthedocs.io/en/stable/networkx.html but that's obviously not the best place for it. I was planning to do a doc reorganization prior to the next release (I opened #328 to track it) and will fix this as part of it.

* Are edge indices assigned in the order the edges were created? If so then I think they are not properties of the graph, i.e. two identical graphs could have different edge indices if they were created in different orders.

They are, the index is just a key for uniquely identifying an edge they get assigned at edge creation time (the internal implementation is there is a Vec in the graph struct for edges and the edge index is the index in that Vec for a particular edge). I agree it's not actually a graph property and it's not used for anything that operates on the graph, it's only really returned by functions that add edges. But, the index is a handle to uniquely identify an edge in a graph and the gap this and #324 are trying to fill is right now there isn't a good way to get the indices for each edge in a graph if you need to get that handle again or to get a mapping from indices to edges (unlike nodes which the graph is actually a python mapping for). While most existing graph functions operate on the tuple of node indices the edge is between, there are some cases (like parallel edges) where being able to use the index instead is useful.