Add `inedges`, `outedges` and `edges(g, v)`

Since the AbstractEdge type is part of the graphs interface, I think it would make sense to have something similar to inneighbors, outneighbors and neighbors, which behaves in pretty much the same way, but returns the appropriate edges, starting/ending at the given vertex.

Something like:

inedges(g,v) = Edge.(inneighbors(g,v), v)
outedges(g,v) = Edge.(v, outneighbors(g,v))
edges(g,v) = outedges(g,v)

(with appropriate types and all that of course)

• The last definition would overload the edges function used to get an iterator over ALL edges, when called without a vertex, which seems sufficiently different to maybe find a different name for that function?
• We seem to have all_neighbors, which could similarly be extended to all_edges(g, v) (If done, having edges(g, v) and all_edges(g, v) but not all_edges(g) would be very strange and confusing)

Since every graph type can come with its own edge type(s), I guess these functions would need to go into the interface and every subsequent package would need to define their own version, calling their own edge constructors. Is that right? Or is there any way around that? (Since most packages seem to use the SimpleGraphs edge anyway, this might not be too big of a problem in terms of adoption?)

If this proposal seems sensible , I would build a PR for it, but, since changing the interface seems quite fundamental, I would like to first get some feedback and suggestions on this.

Start by reviewing the AbstractEdge interface and the existing inneighbors, outneighbors, neighbors, all_neighbors, and edges entry points mentioned in the issue. Determine whether vertex-specific edge iterators belong in the interface and how graph-specific edge types should be constructed; done means the API design is agreed and its interface and adoption impact are defined.