Support routing links on specific static pages with absolute URLs

[towerofnix]

Follow-up to #433 and #434.

In order to support using a static page as the target of a 404-not-found error, we need to specifically route URLs on this page with absolute paths, because it may be served at any path.

This would require indicating that for the span of the current page, any call to to should use the same absolute-routing discussed that would be applied wiki-wide with #433's field - but all other pages should continue to use relative to as normal.

We'd like high-level context functions like generatePageLayout to be responsible for indicating that this routing should be used to HTML-hierarchically nested templates (like linkThing), e.g. in accordance with a slot that generateStaticPage provides.

to is currently part of extraDependencies, i.e. provided completely externally by the selected build mode, which is trouble, as at that point it can't possibly be bound to HTML-hierarchical context. But we might be able to work around this in content functions, since we do have access to what gets provided to the black-box generate function, which we call ourselves in the context of evaluating the template's content — where we do have access to HTML-hierarchical context, as described in #434.

We'd probably, for now, hard-code to as a "special" extra dependency which automatically becomes absolute-routed if the appropriate HTML context is available.

There's concern over what to do when a non-template content function depends on 'to', and we may have to make all content functions depending on 'to' also work with a stationery (thus also depend on 'html'). Room to debate whether or not requiring specifying 'html' as an explicit part of extraDependencies is ever necessary, if you aren't actually using it within content (#436).

Primary concern with this is that templates aren't strictly transparent right now, i.e. if a content function doesn't specify slots, it always returns its generate result directly (not nested in a template), and so slots set on the upper component are actually provided to the lower component. (This is how we make the same slots available on all components based on linkThing, for example.) Since 'to' requires HTML-hierarchical context and thus templates, we'll need to support "transparent" templates (#437) that take any slot keys/values and always pass them directly to the single template returned by their content function (i.e. the content function's generate).