feat: unify php_server logic

[AlliBalliBaba]

Currently the concept of a php_server only exists on the caddy side and not the FrankenPHP side.
Lately we have been moving more and more in a direction of scoping requests or workers to specific php_server blocks.

This PR is an attempt at refactoring the current php_server logic so it is properly mirrored on the FrankenPHP side without BC breaks for library users (and to prevent future bugs like mentioned in #2487)

[AlliBalliBaba]

The public api is now minimized to these 4 functions:

// server registration
func WithServer(idx int, resolvedDocumentRoot string,splitPath []string,env map[string]string) Option

// worker scoping
func WithWorkerServerScope(serverIdx int) WorkerOption
func WithWorkerMatcher(matcherFunc func(*http.Request) bool) WorkerOption

// request scoping, less overhead than WithWorkerRequestScope()
func ServeHTTPSrv(serverIdx int, responseWriter http.ResponseWriter, request *http.Request, opts ...RequestOption) error

This PR also removes the circular fc -> request dependency, which allows simplifying the contextHolder and saving some overhead.

[dunglas]

Why do we need the index to be explicitly passed? Couldn't we generate it and return it if needed?

[AlliBalliBaba]

Same reason as in #2487. The caddy modules might be converted to and from JSON multiple times between parsing, provisioning and the actual server start. So the index must already be present when parsing the Caddyfile.

Not sure how to make it more elegant, maybe somehow like this?

type ServerIdx int

[dunglas]

Hum ok got it. I indeed prefer having a custom opaque type (could be an unit under the hood btw)

[AlliBalliBaba]

Alright I changed it so WithServer additionally returns a Server instance.

type Server struct { idx }
func WithServer(idx int, resolvedDocumentRoot string,splitPath []string,env map[string]string) (Server, Option)
func WithWorkerServerScope(Server) WorkerOption
func Server.ServeHTTP(responseWriter http.ResponseWriter, request *http.Request, opts ...RequestOption) error

I also noticed that currently configuration would bleed across tests, which probably caused some flakiness. I fixed it by purging configuration right after Init().

Also noticed that watcher.Close() will still sometimes hang up in TestHotReload, not sure why (also on main).

When refactoring the context I also fixed some inconsistencies with which logger was being used and which original request method was passed in the debug state.

[AlliBalliBaba]

fyi @henderkes I realized we can just order it like this and there won't be any race or performance degradation across reloads (#2470).

Makes the FrankenPHP Hello World only lag 30% behind the Caddy Hello World in an ideal setup for me.

[henderkes]

Good catch, no need for the channel if scaling is disabled. I'll give this PR a proper review soon,