fix: handroll mpl facilities in graphml

[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).

We added a new dependency (MP11) to use the modern equivalent.

No behavior change.

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 29722980966 vs develop run 29722527837 (8617207304).

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 29722980959 vs develop run 29722527874 (8617207304).

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

Dependency	develop	PR	Δ
mpl	26	25	-1
mp11	0	1	+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)

[jeremy-murphy]

Hmmmm. I'm not really in favour of this change because it leaves a blurry line of when we would justify using mp11 for this sort of thing.
Let's make it a priority to discuss.

[Becheler]

@jeremy-murphy maybe you're right. MP11 is probably pulled transitively anyway. I removed the handroll facilities and brought MP11 in.

[jeremy-murphy]

Ok, cool, yeah, let's prioritise getting rid of mpl, we can debate mp11 later.