docs(html): add a topbar extension slot for post-processing add-ons

[grandixximo]

Following the discussion here, this is reduced to the minimal in-tree piece: a generic, empty extension slot in the docs topbar.

The base build stays minimalist and fetches nothing. The slot (data-lcnc-slot="topbar-end") is an empty placeholder that out-of-tree post-processing can fill, for example to bolt on search, without the LinuxCNC build depending on anything extra. It is empty in the base build, so a plain docs build is unchanged.

As a concrete consumer, I built search as a separate project that downloads the docs artifact, plugs a pagefind search box into this slot, builds a per-language index, and emits searchable docs: https://github.com/grandixximo/linuxcnc-doc-search . Anyone can run their own post-processing against the same slot.

[BsAtHome]

A local search is not a bad idea as such. But it is a bad idea to have this in the tree IMO. Getting code via curl is a Bad Thing^TM, even if it is pinned (not happy about rtai either). If you want a search index, then I think it should be a separate project that a user can do.

[grandixximo]

Thanks, that is fair. The network fetch during the build is the part I am least comfortable with too, so I would rather drop it than defend it on precedent.

Before I rework this, could you help me understand where you would draw the line, so I build the right thing the first time:

• Would a purely static front-end be acceptable in-tree, that is the search box markup, its CSS, and the data-pagefind-ignore markers, with the index itself generated entirely outside the tree by a separate tool run over the built HTML? In that shape the build does no download and gains no extra binary; a plain docs build produces exactly what it does today, and the search box only activates if an index happens to be present alongside it.

• Or is your preference that nothing search-related lives in-tree at all, front-end included, with the whole thing (markup, styling and index) in the separate project?

Either is fine by me. I just want to match what you would be willing to merge before spending the effort. The only goal here is to give the docs the search readers keep asking for, without a fetched binary in the build.

[BsAtHome]

The base build should be a minimalist approach and not expect anything special from the host system. Anything else are bells and whistles that can be bolted on. But it is nice to add support for bells and whistles.

An infrastructure placeholder for a search or any other thing could be provided in-tree. Then, when someone wants it, they can plug into the placeholder and put in their stuff using some post-processing. The trick is to add strategic but generic comments, placeholder classes and data-placeholder attributes in the base HTML where appropriate.
After that you can bolt-on search as a separate project. Or, if anyone wants to, do their own post-processing thing.