refactor: drop direct dependency on Boost.Spirit (graphviz parser)

[Becheler]

Before submitting

• This PR targets the develop branch.
• I searched for an existing PR or issue covering the same change.
• My contribution is licensed under the Boost Software License 1.0.

Type of change

• Bug fix
• New feature or API addition
• Refactor (no behavior change)
• Documentation
• Build, CI, or tooling
• Other (specify below)

Does this PR introduce a breaking change?

• Yes (describe migration impact below)
• No

What this PR does

• graphviz.hpp: removed both Boost.Spirit code paths in the two read_graphviz overloads (they now always call read_graphviz_new)
• dropped the unconditional classic_multi_pass Spirit include.
• BOOST_GRAPH_USE_SPIRIT_PARSER still recognized, but now emits a BOOST_PRAGMA_MESSAGE deprecation notice and redirects to the default parser instead of selecting Spirit.
• Deleted detail/read_graphviz_spirit.hpp (the Spirit DOT reader that pulled in 10 boost/spirit headers).
• test/isomorphism.cpp: removed the incidental #define BOOST_GRAPH_USE_SPIRIT_PARSER
• build.jam and CMakeLists.txt dropped the spirit dependency.

Motivation

The spirit-based graphviz parser has been non default, undocumented and untested for 16 years.
The Boost.Spirit library has 28 direct boost dependencies, and 54 indirect, effectively dragging most of Boost in BGL: https://alandefreitas.github.io/boostdep_graph/libs/spirit.html

This PR removes its implementation, effectively dropping spirit dependency and its direct+transitive chain.

The default parser uses Boost.Regex, that has a much better dependency chain: https://alandefreitas.github.io/boostdep_graph/libs/regex.html

Note: spirit is not effectively removed from the transitive dependencies chain, as Boost.Serialization pulls it in.
A next PR will drop Boost.Serialization for Boost.Core.Serialization.

Note: Boost.Spirit has several dependants that Boost.Graph uses:

• Boost.PropertyTree
• Boost.MPI

Testing

Checklist

• Existing tests pass (b2 in the test/ directory).
• New behavior is covered by a test, or this is a docs / build / refactor change.
• Documentation was updated if user-facing behavior changed.
• No new compiler warnings on the platforms I built against.

[github-actions]

Compiler-warning counts vs develop (auto-generated).
PR run 32455841293 vs develop run 32455728113 (233a8a4316).

Job	Baseline	After	Delta
macos (clang, 14)	703	703	0
macos (clang, 17)	663	663	0
macos (clang, 20)	663	663	0
ubuntu (clang-19, 14)	703	703	0
ubuntu (clang-19, 17)	663	663	0
ubuntu (clang-19, 20)	663	663	0
ubuntu (clang-19, 23)	663	663	0
ubuntu (gcc-14, 14)	874	874	0
ubuntu (gcc-14, 17)	1010	1010	0
ubuntu (gcc-14, 20)	1010	1010	0
ubuntu (gcc-14, 23)	1010	1010	0
windows_msvc_14_3 (msvc-14.3)	962	962	0

[github-actions]

Boost dependency footprint vs develop (auto-generated).
PR run 33410598370 vs develop run 33397888958 (92470302c3).

Header-inclusion weights (graph files pulling each direct dependency in):

Dependency	develop	PR	Δ
spirit	2	0	-2
config	94	93	-1
core	15	14	-1
function	2	1	-1
property_map	80	79	-1
throw_exception	11	10	-1
type_traits	42	41	-1

Transitive Boost modules: 66 → 66 (0)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

🚀 New features to boost your workflow:

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

[mborland]

LGTM. Very straightforward, and helps remove a heavy dependency.

[jeremy-murphy]

One pedantic post-merge request. :)

[jeremy-murphy]

"Deprecated" means that something still exists (and works) but its use is not recommended, so it's not really the right meaning here. I think that text can simply be removed.

Suggested change

	"BOOST_GRAPH_USE_SPIRIT_PARSER is deprecated and no longer has any effect: "
	"BOOST_GRAPH_USE_SPIRIT_PARSER no longer has any effect: "

[Becheler]

You're right! Fixed in #584
I added a comment with deprecated and 1.95 because I will use this in a grep tag to track what must be removed in 1.95.

[jeremy-murphy]

Boost dependency footprint vs develop (auto-generated). PR run 33410598370 vs develop run 33397888958 (92470302c3).

Header-inclusion weights (graph files pulling each direct dependency in):

Dependency develop PR Δ
spirit 2 0 -2
config 94 93 -1
core 15 14 -1
function 2 1 -1
property_map 80 79 -1
throw_exception 11 10 -1
type_traits 42 41 -1
Transitive Boost modules: 66 → 66 (0)

So, removing Boost.Spirit didn't actually remove our dependency on any transitive modules?

[Becheler]

Correct, and it was expected (see the Notes in the PR description), because as long as Boost.PropertyTree is still a direct dependency, it will pull both Boost.Spirit and Boost.Serialization into the transitive dependency chain (those two libs are 55/68 = 80% of the dependency chain weight)

#547 Aims at getting rid of that, with additional benefits:

• x3.5 faster runtime
• x3.7 less memory
• faster compilation time

I am running benchmarks on project compilation times before/after dependencies removal as we speak (compile time dominated by transitive header count). The figure is still a bit shitty, but interesting and kinda confirms that graphviz pulls half the boost galaxy and motivated #566 :

[jeremy-murphy]

#547 Aims at getting rid of that, with additional benefits:

x3.5 faster runtime
x3.7 less memory
faster compilation time

For what part of the library exactly? Just for GraphML or more broadly?