add astar benchmark

[GroteGnoom]

part of #2300

|> Benchmark file: /home/daniel/Documents/igraph/tests/benchmarks/error_checking.c
| singleton graph                                                                      0s      0s      0s
| graph with 50000000 nodes, no edges                                              0.061s   0.01s  0.052s
| vector init of 50000000                                                              0s      0s      0s
| vector fill of 50000000 INFINITY                                                 0.049s  0.006s  0.043s
| vector destroy                                                                   0.001s      0s      0s
| vector fill of 50000000 1s                                                       0.048s  0.006s  0.042s
| 50000000 vertices ring graph astar from 0 to 0, 1x                               0.092s  0.051s  0.041s
| 50000000 vertices ring graph astar from 0 to 50000000 -1, 1x                      4.01s   3.14s  0.865s
| 10000 vertices full graph astar from 0 to 0, 1x                                  0.031s  0.031s      0s
| vector_min on 50000000 numbers 1x                                                0.031s  0.031s      0s
| 2wheap init of 50000000, 1x                                                          0s      0s      0s
| IGRAPH_CALLOC of 50000000 igraph_integer_t, 1x                                       0s      0s      0s
| 2wheap destroy                                                                       0s      0s      0s

Added some benchmarks for things that almost take no time, because they did take a significant amount of time with a debug build with sanitizers on.
So for the case where you path length is negligible:
just checking weights (vector_min) takes up almost all the time for the full graph.
error checking + filling the dists vector (which scales with no_of_nodes) takes about 8/9 of the time for the ring graph. I find it difficult to find where the rest of the time goes.
I've also put in the longest path scenario, then the overhead is less than 1/40.

[codecov]

Codecov Report

Merging #2342 (2aeab22) into master (d789a7e) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2342   +/-   ##
=======================================
  Coverage   83.50%   83.50%           
=======================================
  Files         376      376           
  Lines       61549    61549           
=======================================
  Hits        51399    51399           
  Misses      10150    10150           

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d789a7e...2aeab22. Read the comment docs.

[szhorvat]

Even though this would be difficult for us to implement (without moving to C++), I wanted to mention that some systems store metadata for vectors that indicate the vector contents. For example, I think recent R versions keep track of whether a vector contains NA / NaN. Mathematica appears to do something similar (although strictly speaking it doesn't allow NaNs in vectors). This is much like the cache we use in igraph_t.

If we did have this feature, it could speed up check. We could even set this cache when transferring vectors from R or Mathematica.

But in plain C, there is no good way that I can think of to catch vector modification operations and clear this cache. So I don't think we can do it now. C++ would be different ...

[szhorvat]

In some cases, the input checks can be moved into the core algorithm. This may be an advantage (when the algorithm accesses only a small fraction of edges and their weights) or a disadvantage (which the algorithm accesses the same edge / weight many times).