fix: handroll mpl facilities

[Becheler]

Continue removing MPL from the codebase to limit build times and dependencies.
But this time there is no direct C++ equivalent to the MPL features, so there is a small utility graphml_detail namespace.

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

The GraphML reader and writer kept a compile-time list of the value types they support (bool, int, double, string, and so on) and used three Boost.MPL tools on it:

• mpl::vector (the list of types),
• mpl::for_each (visit each type once, to try each candidate when parsing),
• mpl::find (get a type's position to look up its name).

Their replacement is ~15 lines of plain C++ in a small graphml_detail namespace:

• value_type_list type list,
• for_each_value_type that visits each type in order
• index_of_value_type that gives a type's position.

No behavior change, and no new dependency (no Boost.MP11).

Motivation

Part of the ongoing effort to shrink Boost.Graph's dependency footprint. Boost.MPL is an old, heavy, slow-to-compile library that modern C++ (<type_traits> plus small hand-written helpers) can replace directly. This removes the last direct MPL use from BGL that would not be breaking public API.

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 29508781546 vs develop run 29503421610 (ef7032f35d).

Job	Baseline	After	Delta
macos (clang, 14)	4	4	0
macos (clang, 17)	4	4	0
macos (clang, 20)	4	4	0
ubuntu (clang-19, 14)	4	4	0
ubuntu (clang-19, 17)	4	4	0
ubuntu (clang-19, 20)	4	4	0
ubuntu (clang-19, 23)	4	4	0
ubuntu (gcc-14, 14)	10	10	0
ubuntu (gcc-14, 17)	10	10	0
ubuntu (gcc-14, 20)	10	10	0
ubuntu (gcc-14, 23)	10	10	0
windows_msvc_14_3 (msvc-14.3)	971	971	0

[github-actions]

Boost dependency footprint vs develop (auto-generated).
PR run 29508781359 vs develop run 29503421582 (ef7032f35d).

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

Dependency	develop	PR	Δ
mpl	30	29	-1

Transitive Boost modules: 69 → 69 (0)

[jeremy-murphy]

Now I realise that we're trying to reduce dependencies here, but would it be appropriate to use mp11 to replace the functionality in mpl?

[Becheler]

It was originally the plan to move from MPL to MP11 because I thought the features required across BGL were non trivial.

But all changes are trivial conversions to standard equivalent. It means that pulling in MP11 would be only to avoid those 15 lines.

It would have been > 100 lines for an equivalent that may have justified pulling in MP11 but in that case I don't think it's worth, as it may as well become portable if we go C++17 (looks like the numbers of liens required in c++17 for the same behavior is divided by 2)