Higher parallization for start

[lgrapenthin]

Classic component currently reaches a higher parallelization. Assuming PaymentComponent awaits initialization of some SDK, and UI awaits PaymentComponent this can delay the first render. Functionality of started PaymentComponent is not required in start phase of UI.

A rough guess at an API is to utilize classic component Lifecycle for this. User implements both Lifecycle and LifecycleAsync. The loader will first call Lifecycle start on all components, and they assoc async promises to themselves and expose them, i. e. this phase is 100% classic component. After that, in a second pass all components are started via LifecycleAsync, but start is called with the result of the first pass.

Assuming UI doesn't need PaymentComponent during start now, UI can just implement Lifecycle/start on itself. In start it will see an unloaded PaymentComponent as a dep, but it just starts the UI right away, and, if necessary, assocs a starting promise/channel to itself. Then in LifecycleAsync it somewhere install the loaded PaymentComponent dep, awaits its own starting promise from start.

[lgrapenthin]

Components implementing only Lifecycle would see "pre-started" async components as their dep, not good for adaptive use.

Could "pre-start" only components that impl. LifecycleAsync, but without deps.

Doesn't support partially dependent quick-start where C depends on A B and wants to quick-start with only A and deal with B later.

Alternative approaches

1. Some kind of using-async API - You get selected deps as promises and start faster
2. A magic system dep that allows you to resolve any component from the system asynchronously, once it is loaded.

I like both approaches already more because they introduce no additional behavior to somebody unintersted in this functionality.