feat : Implement full Graphs.jl API and VNAlgorithm dispatch

[mahmudsudo]

• Implement Graphs.jl interface for VNGraph (edges, neighbors, has_edge,
• Add VNEdgeIterator for efficient edge traversal
• Implement optimized VNGraph <-> SimpleGraph conversions
• Add VNAlgorithm trait for dispatching Graphs.jl functions to very_nauty:
  • clique_number
  • chromatic_number
  • connected_components (via graph_nclusters)
• Integrate GraphsInterfaceChecker.jl in test suite for API compliance
• Add GraphsInterfaceChecker as a dependency
• Update README with usage examples and feature list

[codecov]

Codecov Report

❌ Patch coverage is 54.25532% with 43 lines in your changes missing coverage. Please review.
✅ Project coverage is 53.23%. Comparing base (d7a1ec6) to head (0f64532).

Files with missing lines	Patch %	Lines
src/VNGraphs.jl	54.25%	43 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master      #26      +/-   ##
==========================================
+ Coverage   45.90%   53.23%   +7.33%     
==========================================
  Files           1        1              
  Lines          61      139      +78     
==========================================
+ Hits           28       74      +46     
- Misses         33       65      +32     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mahmudsudo]

@Krastanov

[Krastanov]

Thanks for pursuing this, it is very helpful to our fairly small team of volunteers.

For my notes, this seems related to JuliaGraphs/Graphs.jl#507

This PR seems to have a few independent parts, that probably should be submitted as separate PRs. There are general improvements to tests / benchmarks / etc, those are very straightforward to agree on. But there are also changes dependent on Graphs.jl PR 507, which probably will require some bikeshedding to figure out how we want to actually do it -- those changes would be much slower to decide on, let alone approve.

If you split these tasks in separate PRs, one of them will be merged much sooner. I would suggest keeping everything related to 507 separate. I left a few minor comments as well.

[Krastanov]

This file seems to have started depending on external repos. This should be reverted and workflow files should generally be as "default" as possible to ease development.

[Krastanov]

Same issues in this file as above. Also, do not remove the doc build. This repo might not have docs defined yet, but the failing workflow should remain, otherwise we will never remember to get around to making the docs folder. Overall, if something is broken, we should not hide the messenger that reminds us that it is broken.

[Krastanov]

the extras and targets are not necessary -- that type of information should just be kept in test/Project.toml