nix/module: toHyprconf -> toHyprlang

[fufexan]

Describe your PR, what does it fix/add?

Reworks the current Nix to hyprland.conf generator implementation by using a more generic Nix 2 Hyprlang generator.
This allows any application using hyprlang to use this for easy config generation.

This is the second step towards getting this module into Nixpkgs.

Considerations:

• Rename section -> category, to be in line with the documentation.
• Use category[special]:field = value for special categories. This reduces the complexity in finding the special key inside the attrset and then properly ordering it as the first in the generated category. But this poses a question: how should we let the user define these categories?
  • Write them verbatim ("device[some-device:0baf3-952c]" = { sensitivity = 0.3; })
  • Parse a list of devices in the module, rewrite the attrset and pass it to toHyprlang:

    device = [
      {
        name = "some-device:0baf3-952c";
        sensitivity = 0.3;
      }
      {
        # ...
      }
    ];
    
    # this will be transformed to the syntax in the point above

• Ensure nested categories are handled by recursing over them.
• Use category:field = value for everything instead of nested categories (category {...}). This further reduces complexity by having only one code path for all categories.
• Remove indentLevel, no longer needed without expanded categories.
• Change importantPrefixes -> topCommandsPrefixes and also add bottomCommandsPrefixes for greater flexibility. Group these as the first argument (called options from now on).
• Separate attrs into a standalone argument, after the options arg. This is the actual config that will be translated to hyprlang.

CC: @bloxx12 @donovanglover @JohnRTitor @khaneliman @NotAShelf

Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)

Needs testing. Different ideas and constructive criticism welcome.

Is it ready for merging, or does it need work?

Needs testing and discussion.

[JohnRTitor]

Does this mean we can have distro specific configuration now? (which and user config would work together/be merged and then evaluated?)

[fufexan]

In short, no.

The current hyprutils implementation only looks for configs in the order XDG_CONFIG_HOME/hypr -> HOME/.config/hypr -> XDG_CONFIG_DIRS/hypr -> /etc/xdg/hypr.

I've been meaning to work on extending this to accept configs from multiple sources (hypr.d/xx-config.conf), but I'm not sure combining user and system configs is such a great idea by default. Can be done with a simple source though.

[JohnRTitor]

Well as we discussed previously on Nixpkgs, enabling distros to apply default configurations would be helpful in cases where we need things to work out of the box, like importing all env vars (including PATH, XDG_DATA_DIRS), enabling/starting certain services.

These default system configs could just be ignored with a flag like disable-distro-config = true

[fufexan]

This is somewhat out of the scope of this PR, but I'm curious what @vaxerski would say about this.