Refactor cmdline handling & fix ordering

[tarkah]

Previously cmdline loading was happening in many parts of the codebase. This refactors to a cmdline module which is the source of truth for all cmdline loading & final merge logic.

This also fixes a bug where /etc cmdline snippets were added before /usr kernel specific cmdline instead of after.

Testing

Before & after for boot status. Global cmdline is the same, but now we just show it as the merged string:

Before & after for my latest boot entry :

Notice my custom nvme_core entry is last. Also notice moss.fstx comes AFTER quiet splash. This is because this is added by moss manually which I feel follows a similar order of priorty ruling where it should be higher than the shipped cmdline.

[ermo]

The consolidation sounds like a really good idea.

Suggestion for you to ponder:

What if, via either a --debug or a --verbose flag, we kept the vector with different strings in the output of moss boot status --verbose/--debug, such that we can map the entries to their on-disk snippet?

This might yield very useful insight into the order in which files are loaded as snippets (or even excluded by symlinks), where we pretty-print the list like this:

cmdline = [
  "foo", // from <filename>
  "bar", // from <filename>
  // "baz", // from <filename> but excluded by <filename>
]

Where baz is a disabled default in this instance?

Then we give the user insight into how the process works, so they can experiment their way towards a working kernel command-line, while legitimately showing what blsforme "decides"?

[tarkah]

I think that idea. Final merging can then filter out the things decorated as exclusion but we can then debug things nicely. Can we add this as a followup enhancement? I don't think it needs to block this refactor + fix.

[bhh32]

LGTM, needs rebased on main

[tarkah]

LGTM, needs rebased on main

Thanks! Done.