Automate multi-pass rendering

まず go() と go_*() 関数周辺のリクエスト-レスポンスのライフサイクルを追跡し、次に MultiPass 属性、CSS セレクター、x-go リクエストヘッダーがそのフローにどのように組み込まれるかを確認します。Issue で説明されている実行、要素更新、リフレッシュの動作を定義します。完了の条件は、ターミナルブラウザーのリクエスト処理を壊すことなく、文書化されたマルチパスレンダリングのシナリオが機能することです。

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.