feat: add support for specialisations

[Lukas-C]

Closes #120.

Changes

Adds initial support for specialisations by treating them as separate configurations during generation and rekeying operations.
Both NixOS and Home Manager specialisations are supported.
Users of existing configurations should see no changes in usage, it should all just work™.

Notes/Limitations

• Since the specialisations are treated as separate configurations, they require separate values of localStorageDir.
  Otherwise the generated secrets will be immediately garbage collected as orphaned secrets.
  For the same reason, there is no deduplication of secrets between the different specialisations.
• The current implementation makes some effort to avoid name collisions between configurations and specialisations.
  However, if e.g. a configuration with the name foo:bar exists and a separate configuration with the name foo and a specialisation bar exists as well, one will likely overwrite the other and rekeying will not work as expected, if at all.

Testing

A minimal flake that provides a usage example and some basic test cases can be found here.
My personal config that uses the derivation storage mode also appears to work with the implementation.

Todo

• Documentation: Add a short section about specialisations, how they basically behave like configurations and are as such subject to the same limitations, e.g. needing separate localStorageDirs. A note about the name collision issue above may also be not a bad idea.

[Lukas-C]

Having had some time to think about this, I still don't like the issue with name collisions potentially silently swallowing configurations. While this may be only be a minor issue in practice, I think a better way to approach this may be to change the nodes attribute set into a list of attribute sets. These could then carry the config as well as any additional metadata/debug information instead of having to stuff all of that into the attribute key. However, this requires a larger refactor and I am not confident enough that I have the overview to implement this properly without some sort of test suite. Therefore I would leave the PR as is for now and deal with this separately if this becomes an issue.