[GR-54854] Support linking as an independent build step

[nreid260]

Is your feature request related to a problem? Please describe.

native-image executes linking as a subprocess under itself. This makes it difficult to use custom linking setups.

We use Bazel as our build system, which is designed to run linking as a separate process after compilation. This linking step also has some additional behaviours that are error-prone to re-implement (e.g. injected data, stdlibs, flags, linker scripts).

On top of this, Bazel caches files between build processes. Because native-image runs linking as a subprocess, the .o files created from JVM bytecode can't be cached. That means during development, linker errors force us to rerun all the .o file generation steps.

Describe the solution you'd like.

My ideal solution would be if native-image could emit .o files (and possibly linker args) as a final output. Then I could propagate those to our usual linking logic.

Describe who do you think will benefit the most.

This is admittedly a niche feature. I think it would mostly benefit very advanced native-image users. Maybe there's some benefit to native-image devs for debugging.

Describe alternatives you've considered.

I have tried passing a "fake" linker executable to capture and propagate linking inputs. However, there's some kind of "query" linking before the "main" linking. If the "query" executable isn't produced, native-image crashes, so this capture technique seems impossible today.

[fernando-valdez]

Created an internal ticket GR-54854