Everywhere: Refactor version reporting so that the Kernel is the one source of truth

[kleinesfilmroellchen]

There's quite some stuff in this PR but it basically amounts to:

• Get rid of the three distinct version information sources there are right now (Core::Version::SERENITY_VERSION, /res/version.ini, uname syscall).
• Make the uname syscall the one source of truth for version information.
• Bake the actual version information into the Kernel; get rid of /res/version.ini.
• Make uname(1) (the utility) POSIX-compliant by reporting the git commit hash with -v.

Fixes #15071

[nico]

Embedding git revisions in binaries means that two identical source trees except for a comment change somewhere produce different binaries.

The cool way to handle this is to have deterministic builds and print the hash of the build outputs, not the inputs 😛

[linusg]

two identical source trees except for a comment change somewhere produce different binaries.

In my mind that's an acceptable drawback / feature ;^), but I also understand the desire for reproducible builds. The problem of using the build output hash is that it's basically meaningless, compared to being able to trace a build back to a specific commit in the serenity repo.

[kleinesfilmroellchen]

Embedding git revisions in binaries means that two identical source trees except for a comment change somewhere produce different binaries.

As long as you're not committing, the binaries will be the same. Either way, I don't know the best approach forward, but to me, it feels beside the point for this specific PR. We can have an additional discussion about how there's a hard-coded version string that some parts of userland use while Core::Version can already read /res/version just fine, but again, besides the point for this PR, :yaksteps: :^) What do you think, @linusg ?

[nico]

it's basically meaningless, compared to being able to trace a build back to a specific commit in the serenity repo.

Au contraire! If your build is deterministic, the output hash clearly corresponds to one (or more! If there are multiple revs producing the same output) input rev.

[linusg]

Sure, but unless someone will be keeping a list of build hashes mapping to their corresponding commit hashes, I'm not sure how I would determine which "version" of serenity I'm running just from that?

[kleinesfilmroellchen]

Ah, so that's why you need it. I just went with the minimal POSIX APIs we need to have.

[stale[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions!

[circl-lastname]

Is this still active?

[kleinesfilmroellchen]

I think it is totally mergeable, yes.