drop dependency on Boost.Bimap and Boost.Lambda

[Becheler]

Drop Boost.Bimap dependency

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

Drop the Boost.Bimap dependency, adds a thin wrapper with similar interface.

Motivation

two_graphs_common_spanning_trees.hpp is the only user of Bimap in Boost.Graph (and actually in the entire Boost ecosystem).

• It pulls 26 modules (mpl, multi_index, mp11, lambda, ...) for a container used read-only. It's a blocker to get rid of MPL and other deprecated Boost libs since they will keep popping up through the transitive dependencies chain.
• Most of the interface is unused. Each bimap is built once then read via four ops: left.at, right.at, right.find, insert.
• Bimap is over-general. The position side is a dense range 0..n-1 (plain array indexing), so only edge-to-position needs a map. A std::vector plus a std::map cover both directions; a bidirectional-map library is the wrong tool.

Testing

Same tests hold.

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 29821241901 vs develop run 29738450065 (b355d10ecc).

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

Dependency	develop	PR	Δ
bimap	1	0	-1

Transitive Boost modules: 68 → 66 (-2)

• removed: bimap, lambda

[github-actions]

Compiler-warning counts vs develop (auto-generated).
PR run 29821243416 vs develop run 29738450095 (b355d10ecc).

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	953	-18

[jeremy-murphy]

I just want to look at this on a proper computer screen but I'm feeling very favourable towards it. 😅

[Becheler]

Take your time the PR is not going anywhere ahaha

[jeremy-murphy]

By convention, at(std::size_t i) is checked access, meaning it will throw an exception if i is out of range. Ideally, we want to provide operator[](std::size_t i), which is unchecked, although I can see that will mean a lot of trivial changes from at(i) to [i].

[Becheler]

I think I disagree with this direction, that is modifying the public API semantics based on a change of the implementation detail.

The point of the wrapper was to serve as a switch with the old Bimap interface. I do think we should still respect its semantics (who knows, if std::bimap arrives someday).

Concretely, for a map the semantics is different between at() and operator[], particularly concerning insertion/throwing.

I was ok changing the internal access because we have the guarantee it will remain in scope, but from the calling site perspective we must preserve the semantics that we don't intend to insert an element (or whatever UB Bimap would be doing if unchecked access) if it does not exist.

Happy to discuss though, as you said its a trivial change, but I keep thinking they had a reason to use the at(i) rather than [i]