feat: Introduce support for erofs initrds

[craciunoiuc]

Remaining ideas to discuss once @nderjung finds some time:

• worth creating/finding an erofs library to handle packaging? (my opinion: for now, no, if use case becomes wide-spread and unwieldly, then start doing it)
• worth creating subdirectories for initrd implementations? Right now we have CPIO, and EROFS, but we might have more in the future, and might need those fancy interfaces + packages + structures (my opinion: yes, but for this very early use case, we can keep it like this)
• worth writing a CPIO->EROFS converter? Right now it throws an error and informs people they should unpack with cpio/bsdcpio first and then run on the directory (my opinion: no, not needed; only people who would turn CPIO files to EROFS files most probably already have these tools, meaning they are devs)

Prerequisite checklist

• Read the contribution guidelines regarding submitting new changes to the project;
• Tested your changes against relevant architectures and platforms;
• Ran make fmt on your commit series before opening this PR;
• Updated relevant documentation.

Description of changes

[craciunoiuc]

Action fail is expected, it adds new interface elements that are not available in the action, but can't be bumped either

[nderjung]

worth creating/finding an erofs library to handle packaging? (my opinion: for now, no, if use case becomes wide-spread and unwieldly, then start doing it)

Yes. Right now this invokes mkfs.erofs which won't work on other systems, i.e. macOS. For internal testing and validation this implementation is fine but we should iterate (see points below).

worth creating subdirectories for initrd implementations? Right now we have CPIO, and EROFS, but we might have more in the future, and might need those fancy interfaces + packages + structures (my opinion: yes, but for this very early use case, we can keep it like this)

Yes. It's better to have an interface which we can use to to output different formats (which is true given our roadmap) in the future. Tarball, squashfs, etc.

worth writing a CPIO->EROFS converter? Right now it throws an error and informs people they should unpack with cpio/bsdcpio first and then run on the directory (my opinion: no, not needed; only people who would turn CPIO files to EROFS files most probably already have these tools, meaning they are devs)

No. Each initrd "source" should emit the resulting filesystem as an intermediate filesystem representation. This intermediate filesystem representation should be passable into a converter which serializes appropriately based on its relevant headers/format. This will similarly be true for a de-serialization process which would allow the user to convert a given output format back into the intermediate filesystem representaton and thus into another format.

[craciunoiuc]

For 1. I don't think it's that bad. I could find the C code that is built into the mkfs.erofs binary, so theoretically we could "translate" it, but maybe we can pass this to a GSoC student or similar :D