refactor: drop direct dependency on Boost.Serialization

[Becheler]

Remove dependency to Boost.Serialization

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

• Phase out of serialization nvp utilities to boost.core.serialization
• Use a forward declaration trick to decouple BGL from Serialization.

Motivation

Boost.Serialization is one of the heaviest Boost.Library along with Spirit: 22 direct dependencies, 55 total, effectively dragging most of Boost in default build: https://alandefreitas.github.io/boostdep_graph/libs/serialization.html

In contrast, Boost.Core.Serialization has 3 dependencies: https://alandefreitas.github.io/boostdep_graph/libs/core.html

We switch to Boost.Core.Serialization dependencies and use a forward declaration trick inspired by Peter Dimov uuid trick to remove direct coupling on Boost.Serialization (the user who needs Serialization will pull its headers anyway): https://github.com/boostorg/uuid/blob/2aa25a3afe023c5324d1b13015a65f67bfaef08c/include/boost/uuid/uuid.hpp#L344-L357

Some Serialization stuff for property map is behind an MPI guard: this is actually Boost.Parallel territory, and looks like a remnant of modularization BGL/PBGL. This should be exported to PBGL rather than polluting BGL, but it's a cross-repo PR and outside of the current scope.

Testing

The current test is unchanged, we just add a static assertion to verify the tracking level is unchanged (it exists to guarantee that non-const graphs can be serialized, removing it would cause a compilation error deep inside Serialization if the user tries to serialize a non-const graph).

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]

Boost dependency footprint vs develop (auto-generated).
PR run 31477727429 vs develop run 31467777307 (cb986e55d5).

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

Dependency	develop	PR	Δ
serialization	2	0	-2
type_traits	41	42	+1
core	13	15	+2

Transitive Boost modules: 68 → 68 (0)

[github-actions]

Compiler-warning counts vs develop (auto-generated).
PR run 31477727461 vs develop run 31467777283 (cb986e55d5).

Job	Baseline	After	Delta
macos (clang, 14)	681	681	0
macos (clang, 17)	641	641	0
macos (clang, 20)	641	641	0
ubuntu (clang-19, 14)	681	681	0
ubuntu (clang-19, 17)	641	641	0
ubuntu (clang-19, 20)	641	641	0
ubuntu (clang-19, 23)	641	641	0
ubuntu (gcc-14, 14)	827	827	0
ubuntu (gcc-14, 17)	949	949	0
ubuntu (gcc-14, 20)	949	949	0
ubuntu (gcc-14, 23)	949	949	0
windows_msvc_14_3 (msvc-14.3)	962	962	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.

[jeremy-murphy]

I like the design behind Boost.Core.Serialization in that it's providing just enough for client libraries like Graph to define helper functions for proper Serialization should the user actually want to use it.

[jeremy-murphy]

After you merge this, please update the review for removing Spirit so that, I assume, the stats with the delta will update.