fix merge_vertices

[etiennedeg]

Porting my old PR to the new repo

---

Fix for 1586.

merge_vertices was also mutating vs, this is fixed.

I also restricted the definition of the method from AbstractGraph to AbstractSimpleGraph, because it assumes the vertices are a OneTo range. Tell me if you think I should not change this method definition, but I think a more general method would be quite meaningless.

I harmonized it a bit with the in-place method and did some little optimizations. It is possible to do a little bit better by updating new_vertex_ids only for vertices above merged_vertex, should I do it, or is it ok like this? I hope I didn't break anything.

This is my first PR and I have a few questions :

• I see that some tests, notably for Operators.jl, are in a testset "$g" for g in testlargegraphs(g3) run on different types, but don't rely on g, so these are run multiple times. Should we move these to another static testset ? I added a new test to cover the issue, and put it with these tests, but I can modify that.
• Some functions (like complement) are defined for the concrete types Graph and DiGraph. Should these be implemented for AbstractSimpleGraph (with eventually the Trait IsDirected, as it is done in reverse?
• From when is it worth to specialize methods for AbstractSimpleGraphs? Also, it seems that a lot of methods defined for AbstractGraph use the assumption that vertices form a continuous range (for example a_star, if I'm not mistaking, as it uses vertices as indices of a Vector).

[codecov]

Codecov Report

Merging #11 (985daa8) into master (5db2e33) will decrease coverage by 0.00%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master      #11      +/-   ##
==========================================
- Coverage   99.45%   99.45%   -0.01%     
==========================================
  Files         106      106              
  Lines        5551     5544       -7     
==========================================
- Hits         5521     5514       -7     
  Misses         30       30              

[jpfairbanks]

Some functions (like complement) are defined for the concrete types Graph and DiGraph. Should these be implemented for AbstractSimpleGraph (with eventually the Trait IsDirected, as it is done in reverse?

Yes they probably should be defined for abstract graphs

From when is it worth to specialize methods for AbstractSimpleGraphs? Also, it seems that a lot of methods defined for AbstractGraph use the assumption that vertices form a continuous range (for example a_star, if I'm not mistaking, as it uses vertices as indices of a Vector).

The assumption of 1:nv is really baked into the library. Removing that assumption would require a big rewrite.