Adds an afterStart pseudo-event to LoomServer observable by Router implementations

[ljnelson]

This PR adds an afterStart "event" in the same spirit as the existing beforeStart and afterStop "events" that are found in ServerLifecycle implementations (but dispatchable only via Router implementations).

I am not sure that I have written it correctly and expect it to be discussed thoroughly. My goal with this first pass has been to simply preserve the spirit and style of the preexisting "event" notifications in LoomServer, together with preserving design decisions made internally by members of the Helidon team.

LoomServer (package private) has a collection of (package private) ServerListener instances, indexed by name, that have access to Router implementations internally. I found that to preserve the spirit of the existing code I had to provide access to these Routers, since they are currently the only recipients of beforeStart and afterStop "events", and so, it seemed to me, should be the recipients of (the new) afterStart "event".

Internal discussions said that the notification mechanism should be serial, i.e. not in parallel, so I did not use the parallel method to dispatch the afterStart "event".

Currently if an afterStart "observer" throws an exception undefined behavior occurs. I believe that there will be many good opinions on what should happen instead.

Internal discussions also said that the new "event" payload should be the WebServer itself so there is now a bidirectional dependency between, e.g., Router and WebServer. I'm not sure if this was intended to be the case.

I also noticed that Router is effectively implementing the ServerLifecycle contract, but does not officially implement it, so I didn't add that.

I expect that there will be many changes requested, possibly even a completely different architecture for this originally-intended-to-be-small change.

[tjquinno]

I share what I think is your concern, Laird: currently, routing has to be involved for these events to be delivered.

Here's a concrete example that argues for supporting a non-routing-based way to learn of these server lifecycle events.

The code which manages metrics for virtual threads starts a Java Flight Recorder RecordingStream to receive virtual-thread related events from JFR. That code, which does not and should not rely on any routing information, has no way to learn when the server is about to/has shut down, so it cannot explicitly close the RecordingStream when the server is shutting down.

(Recall that meters can be retrieved programmatically from code in the server and not only by the metrics endpoint, so it's important to maintain these measurements apart from if they are ever retrieved via HTTP.)

Practically speaking that's fine because we need the RecordingStream as long as the server is up, and JVM shutdown is the ultimate clean-up.

But some recent work by @danielkec is somewhat disrupted by this - see #9687.

Arguably ServerLifecycle should be outside the webserver component and its implementations notified without routing...it's probably rare, but there could be Helidon servers that do not include a webserver but there are certainly components (like metrics) that should be able to respond to server lifecycle events without relying on routing.