Sketch Linker implementation.

[evacchi]

I started looking at the Go implementation, and I think this is VERY ROUGHLY what happens there. In particular, take a look at
LinkedModules link() in Linker.

Essentially the flow is the same as before, except that, when a Plugin is created with the Plugin.Builder, on build() the Linker is instantiated and wires together all the Module.Builder instances. (Yes, this is very Java). I moved most of the logic from the Plugin constructor to this new Linker class.

Adding a bunch of folks as reviewer, feel free to add some comments if you have some time.

Will backfill the tests, hence why this is a Draft. Good thing the single-module version still works, meaning at least I am doing something right.

[evacchi]

The latest SNAPSHOT on main includes a Store facility that
does not track direct dependencies between components; it does
not recursively instantiate required modules, it just assumes
that instantiating a given module at a given moment means
that all the requirements are satisfied at that time.

The missing bit to turning the Store into a linker
is a layer that tracks dependencies, linearizes them into
a sequence, and then instantiate them in order.
We also track cycles, introducing an indirection (a trampoline)
to break out of them.

[evacchi]

this is not strictly related to this PR, but it's necessary to compile this under graalvm native image. This flag is true when the native image builder it's running. We want to make sure that the code path below is pruned at build-time, because the AoT in its current state is not compatible with the way native image works.

[evacchi]

I suppose we might want to wait for a release before merging