Rework recipient lines and recipient parsing to be pluggable

[str4d]

Currently each supported recipient line and type is hard-coded and special-cased. While this is nice for e.g. building the enums, it makes it harder to extend with new recipient types, which is the single joint in the age format. In the interest of keeping that joint well oiled, we should rework the recipient line handling logic to be pluggable. Initially this would be an internal decision, but it should be usable via the library interface, and maybe later via binary plugins for the rage tool suit.

Related to #36.

[str4d]

After discussion at HACS 2020, it is likely that we will create a plugin system where the main implementations communicate with separate plugin binaries via a standard I/O interface. I'm still inclined to figure out an internal trait for handling recipient lines and keys though, as it means that adding support for more recipient lines is not a breaking change (though I could probably use incomplete enums for that), and removing support for recipient lines is not a breaking change.

[str4d]

#52 and #56 have improved recipient line parsing to the point that it could be behind an internal trait. Serialization still needs to be refactored.