Better API for application runtime keys

[samoht]

Tentative new API based on discussions in #1483
Use: mirage/mirage-skeleton#382

There are a few more cleanup to do but the changes are actually quite simple:

• the main function in config.ml now takes a list of runtime keys - so you do not need to register them in unikernel.ml anymore - just write normal Cmdliner terms in there
• all the devices now takes the evaluated runtime keys as parameters - this is a bit tricky sometimes for devices with a varying number of parameters, but I think that's not too bad.

You can see the main changes in test/functoria/e2e/app/app.ml and test/functoria/e2e/app/config.ml

@reynir and @hannesm: that would be great to have your input to know if this is going in the right direction.

[hannesm]

We discussed in the MirageOS meeting on Feb 26th (yesterday) that this sounds nice (and is likely the way to go). One question that was raised if we can remove the dependency that mirage depends on mirage-runtime (and functoria depends on functoria-runtime). If this is the case, the mirage utility would be independent of e.g. lwt :)

[hannesm]

Related to my earlier comment, the functoria does no longer depend on functoria-runtime within this PR (opam file of functoria needs to be updated), and mirage refers in lib/mirage/mirage_runtime_arg.mli Mirage_runtime.log_threshold -- but elsewhere I already mentioned that I'm not sure about this mirage_runtime_arg module, where it is useful, and why not just pass strings through.

[hannesm]

these comments shouldn't hinder a merge and release -- I have not done a review of this PR though (and won't have time soon for this).

[samoht]

I've rebased this on top of main -- the changes are now just moving the runtime args from Key_gen to the parameters of the connect and start functions. @mirage/core reviews are welcome, especially the CHANGES file :p