Handle per-profile configuration consistently

[getchoo]

By per-profile configuration, I'm referring to options like

• catppuccin.vscode.profiles.<name>.enable
• catppuccin.{firefox,librewolf,floorp}.profiles.<name>.enable
• catppuccin.thunderbird.profile

Currently, these take three approaches (respectively):

• Per-profile configuration
  • There are catppuccin options mapping to each profile managed by the parent module
  • Each of these options respect the global catppuccin.enable option by default
• Per-port + per-profile configuration
  • There are root enable, flavor, etc. catppuccin options for the port, and profiles.<name> options that map to each profile managed by the parent module (catppuccin.firefox)
  • The port's enable option (i.e., catppuccin.firefox.enable) respects the global catppuccin.enable
  • Each profile's enable option respects the ports enable option
  • This is a bit confusing IMO, as now uses need to be concerned over both the "global" catppuccin enable, as well as the per-port catppuccin.<port>.enable option in order to determine the default of catppuccin.<port>.profiles.<name>.enable
  • This is the most complicated to implement
• Single-profile configuration
  • There is a single enable option like regular ports, but it's accompanied by a profile option mapping to a single profile managed by the parent module (programs.thunderbird)
  • The enable option respects the global catppuccin.enable, per usual
  • This is probably the worst case scenario for parent modules that support per-profile configuration, as we're limited to one
  • It's the easiest to implement

I think most options should follow the first approach, to be consistent with the upstream home-manager/NixOS modules and have APIs that are simple to understand/implement. Exceptions can of course be made for parent modules that have different behavior, but we'll cross that bridge if/when we get there

So here are some PRs that progress towards that. And feel free to leave feedback!