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.

[fufexan]

Even simpler now, in case y'all found this too daunting to review :P

After implementing flattenAttrs I searched Nixpkgs PRs and found this. 🤷‍♂️

[NotAShelf]

I have nothing left to add, LGTM.

One thing that might possibly come to bite you in the back is the fact that nixpkgs requires test for new library functions, but since this'll be put in generators that might be necessary.

[fufexan]

One thing that might possibly come to bite you in the back is the fact that nixpkgs requires test for new library functions, but since this'll be put in generators that might be necessary.

Tests for these functions should be relatively easy to implement.

[fufexan]

Since there haven't been any objections, I'll merge this.