docs: generate a browsable libosrm C++ API reference

[antheducation]

The problem

docs/libosrm.md is the only documentation the C++ library has, and it documents the contract
by telling the reader where to go and look:

Here is all you ever wanted to know about libosrm, that is a short description of what the
types do and where to find documentation on it:

…followed by a bullet list in which EngineConfig, OSRM, Status, TableParameters,
BaseParameters, Coordinate and JSON are each a hyperlink to a header file on GitHub. That
structure has been in place since #3441 in December 2016.

Meanwhile the HTTP API and the Node.js API each have a real reference page on project-osrm.org.
An embedder who wants to know what RouteParameters::annotations accepts, or what Status
distinguishes, ends up reading include/engine/api/route_parameters.hpp in a browser tab.

What this adds

tools/api-docs/build.py — one command that turns those same headers into a reference:

python tools/api-docs/build.py            # -> build/api-docs/site

For the pinned commit that is 58 pages covering 421 symbols, with 355 links back to the exact
file and line each symbol was read from. The output is published by the companion PR at
https://project-osrm.org/libosrm-api/ — on the project's own domain, in the repository that
already stores the built documentation for every release from v5.5.0 to v26.6.1.

docs/libosrm.md and the README's documentation list now point at it. The prose in
docs/libosrm.md is left alone: it explains how the pieces fit together, which a generated
reference is bad at, and it now hands off to the reference for the per-symbol detail, which
prose is bad at.

What it does not do

• Nothing is added to the C++ build. No new CMake target, no new dependency, no submodule.
  tools/api-docs/ is inert unless you run it.
• No header is modified. promote_comments.py copies the headers into build/api-docs/src
  and promotes the // prose that already sits above a declaration to /// there, because
  Doxygen ignores //. The transform is line-preserving, so a promoted line keeps its original
  number and the source links stay true. It is conservative: BSD file banners, clang-format
  and NOLINT directives, and commented-out code are all left alone.
• No CI change. I have deliberately not touched .github/workflows/. The reference is
  regenerated when someone runs the command; if you would rather it rebuilt on release
  alongside the VitePress docs, I am happy to add that in this PR — I did not want to put an
  npx fetch on your pipeline without you asking for it.
• Scope is deliberately narrow. INPUT in tools/api-docs/Doxyfile is exactly the headers
  docs/libosrm.md points at plus the types they expose in their signatures. Pointing Doxygen
  at include/ as a whole would pull in the extractor, partitioner, customizer and internal
  engine trees, which are not part of what embedders code against.

How it is rendered

Doxygen produces XML only; the pages are rendered from that XML by
Sourcey (npx --yes sourcey@3.6.5, pinned to an exact version, fetched
on demand — not added to package.json). Output is plain static HTML with no runtime
dependencies, which is why it can be dropped straight into the site repo.

Three things the run turned up, if you want them

1. The result out-parameter of all six osrm::OSRM service methods (Route, Table,
   Nearest, Match, Trip, Tile) is undocumented, so the reference shows the signature
   without saying what gets written into it. Six @param result lines would fix it.
2. include/osrm/*.hpp are alias headers re-exporting engine::api::*, so several types appear
   twice in the reference (osrm::RouteParameters and osrm::engine::api::RouteParameters).
   Harmless, but a @copydoc or an EXCLUDE line would tidy it.
3. The header prose is // throughout. If you ever want to drop the pre-pass, converting the
   public headers to /// in place would do it, and would make the comments visible to
   clangd/IDE tooling as well.

Happy to split this, rename anything, or move the generator wherever you prefer.

[antheducation]

Companion PR that publishes the rendered output on the site: Project-OSRM/project-osrm.github.com#46