chore(sdk): replace generics for builders, with generics for their output

[emhane]

Closes #9543, alternative to #11204

POC: bijective relation builder-output<>builder, allows for output to provide its builder

The builders' output types that are used through out the program, whereas the builders are only used once and don't leave the node builder scope. It's more lightweight, if we access the builder via the output, output -> builder. rather than currently on main

<N::ComponentsBuilder as NodeComponentsBuilder<RethFullAdapter<DB, N>>>::Components

we should access

N::Components

Builders can definitely rather be used as trait objects than (long complex) generics for the reason that their build function is only called once, and only relevant where it's called. The builder generics aren't really helpful to read, but propagate nonetheless and quickly get overwhelmingly complex - unless we use the BuilderProvider pattern. We don't really care about what the builder type is, we just care about that
(i) we can use it when we need to, and that
(ii) it builds the output type we wish to use through the rest of the program - we are more concerned about the output type.
Atm it feels like it's hard to find the actual output types in the node builder code, they are nested somewhere in associated types of the builders. The builder types are most of what we see reading that code, but we want to see the output types most. The builder types are just a means to an end, the components = reth's substance.

Generics are cumbersome, and should be reserved for types that are used often by the program. For example the consensus type or task spawner type in reth have no need to be dynamically dispatched, because they never change, i.e. we don't have a list of different types of consensus types in some struct field, and they are loaded often by the program, e.g. the spawn trait method on type that impl TaskSpawner is called many times during the program.

[mattsse]

the motivation of the referenced pr was to make this stateful so we can move have something like an rpc builder, e.g. op rpc setup needs external input (sequencer URL)
having the NodeAddons stateful would be first step towards that.

[emhane]

the one doesn't exclude the other, the node add ons can be passed to the BuilderProvider::Ctx

[mattsse]

we've since moved this differently and introduced NodeAddOns