Automate multi-pass rendering

By default, all page functionality should be put into go()

However, make it so any go_*() function will be called, allowing for functionality to be split into separate functions.

For example, on a page where there's basic functionality, and then a chart is rendered, put all the required functionality in go() as usual, but move the chart rendering into go_chart().

On a normal page request, all go() and go_*() functions are executed (in any order, technically allowing for concurrent execution).

The fancy functionality comes from tagging a go function with a #[MultiPass()] attribute.

The go_chart() function can be tagged with a CSS selector to the element it is isolated to:

#[MultiPass("main .data>.chart")]
function go_chart(Element $element):void {
  // Now $element is already selected from the document.
}

The fancy stuff can be done by now only executing the main go() function on the first render, and each individual Multi-Pass element being updated with an automated fetch() request from the client side.

Fetch request with "x-go: chart" header to only render that one function (to do multi pass rendering)

There can be more fancy stuff automated by specifying update regularity, so a page can be kept up to date, like #[MultiPass("main .data>.chart", 3)] // update every 3 seconds.

Maybe web services can be added for #450 , but the main priority is to respect the request-response lifecycle, so WebEngine apps can still be completely used within a terminal browser.

Start by tracing the request-response lifecycle around go() and go_*() functions, then review how the MultiPass attribute, CSS selector, and x-go request header would fit into that flow. Define the execution, element-update, and refresh behavior described in the issue; done means the documented multi-pass rendering scenarios work without breaking terminal-browser request handling.