[FEATURE] Adding support for age.Plugin identities

[AnomalRoil]

Sorry for this being a big, messy PR; I had to touch quite a few things and the age plugin support itself is still experimental, so this is currently based on the age/plugin feature branch from age.

On the bright side: yubikey age identities do work really nicely as far as I can tell!

Closes #2900, closes #2260, and fixes partially #2619.

A few points worth mentioning that might warrant some discussion:

• most notably, I had to edit the format we use for storing identities in our key ring, because plugin identities do not allow to necessarily derive the right recipient easily (or include secret key material when doing so), so I am now storing in our identity file the identities in the following format:

  AGE-PLUGIN-YUBIKEY-1GK...|age1yubikey1qt2r...
  AGE-SECRET-KEY-10CW...
  

  using | to separate the actual identity encoding from the recipient encoding. This has some trickling effects on how we parse age identities
• I had to add the notion of wrapped identities and recipients, because plugin.Identity and Recipient don't have any easy way to go back to their "encoded" string format with the current proposed age plugin interfaces.
• I had to add a sorting function on the recipients when encrypting with age, because age by default tries to decrypt in the order of the stanzas, and if we do have a native identity on our machine, we probably want to use that first before using a hardware token.

On a side node, overall, the age backend code is fairly messy and it might warrant some big refactoring at some point.

Disclaimer: I have only tested that on my own machine, not with a team using age as a backend, and yeah tests are somewhat lacking, I'll try to add a few tests with example identities and recipients in the coming days.

[dominikschulz]

Nice, thanks a lot.

I think my only ask is to add some of the details from the PR message to the PR itself (e.g. wrappedIdentity and some notes about the recipient format).

[dominikschulz]

Very nice!