[EkaOS] Expose more priority operators for better composition between repositories

[jonringer]

In nixpkgs, you just had "what was in nixpkgs, and what is outside of it". However, since Ekapkgs is embracing the poly-repo structure we will want at the very least some way to say, "I didn't define this option, but now that I have more knowledge, I can set a better default value".

Terminology:

• "Option Module": Module which exposes options and a related config section specific to only that domain (E.g. boot.nix)
• "Profile Module": Module which contains opinionated configuration of a system (e.g. configuration.nix)

Priority	Value	New?	Description	Ekapkgs Use case
mkOptionDefault	1500		What is used with mkOption's default field	unchanged
mkDefault	1000		Used in non-user "option modules" to declare defaults	Setting defaults in corepkgs or in modules which define the option
mkPreferredDefault	500	Y	Used in non-user modules to declare defaults	Setting defaults in ekapkgs which may conflict with corepkgs, in which a better default can be selected with more config fidelity
	100		Used in "profiles"/user configs to set desired values
mkPreferred	75	Y	Used in non-user modules to declare defaults	Setting defaults in ekaos-hardware for hardware enablement, discouraged outside of "anything else would likely be incorrect"
mkForce	50		Used to override previous definitions	unchanged
mkVMOverride	10		Used by system tests to override any other configuration	unchanged

[ic4-y]

While I think the idea as such is great, I am not sure I'd go with mkDefault -> mkPreferredDefault -> mkPreferred ... I think the mk prefix is somewhat Haskell inspired, right? I always found it super confusing.

When looking at the source code, it turns out they are all just varieties of mkOverride with different priorities.

I'll write some more on Discord. It's better for a loose discussion of this