[RFC] Decide on linking

[asl]

Currently the object code emitter produces a relocatable ELF file. In order to be run on the VM the object files should undergo the linking process.

Overall, for EraVM linking is more or less trivial, as there is (almost) no distinction between code and data and essentially we are having only a single static relocation.

Still, something should be done here. I am seeing few possibilities:

1. Teach lld to link these ELF files. Likely an overkill, but would provide a unified model with e.g. static libraries support, even LTO and other bells and whistles.
2. Teach EraVM loader to load ELF object files directly. After all, single relocation and flat address space make dynamic loader implementation quite simple.
3. Implement something simple akin to objcopy that would merge all sections together and resolve the relocation

Tagging @atrosinenko @hedgar2017 @akiramenai @sayon

[akiramenai]

It's a wider issue actually.
We have implicit requirements we haven't discussed yet.

1. We don't want to ship multiple files to user. It's the reason for our hacky approach to runtime libraries. So we want the linker and other tools to be linked with our frontend. @hedgar2017 could explain this better if needed.
2. We have another target, EVM, so we want to share linker solution with it.

I will elaborate on both after I finish with the review.

[akiramenai]

From our past experience, we tend toward option 1. We have already done some experiments with LLD for EVM target, and from our current understanding option 1 doesn't look extremely effortful (N.B. I shared a document about some specifics we have in EVM and likely in EraVM with regards to linking).
@asl from our past conversations, I remember that you mentioned that it wouldn't be as easy as we expect, so could you elaborate on the issues we are going to face should we choose this design?