Automate multi-pass rendering

Inizia tracciando il ciclo di vita richiesta-risposta attorno alle funzioni go() e go_*(), quindi esamina come l’attributo MultiPass, il selettore CSS e l’header di richiesta x-go si inserirebbero in quel flusso. Definisci il comportamento di esecuzione, aggiornamento degli elementi e refresh descritto nell’issue; il lavoro è completo quando gli scenari documentati di rendering multi-pass funzionano senza interrompere la gestione delle richieste del browser da terminale.

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.