If a user is ever added or removed to a recipients list, currently the file has to be explicitly decrypted and re-encrypted. Instead, we should provide a command to do so in-place, specifically without dropping anything to the filesystem (for security reasons).

When sekrets reads a recipient file (as specified by '--recipients'), it should be able to interpret and use "includes", e.g. 'include front-end-devs.txt', where the file name is a path relative to the recipient file (or maybe absolute is available? Could be tricky Windows vs. POSIX). An example recipient file using includes might be:

include front-end-devs.txt
include ../qa/front-end-qa.txt
[email protected] C40657BA9679BCD93BD4559D0C3D377FF6345B4A

When the output filename is specified as a directory without an actual filename, sekrets should use the input filename. Right now, this behavior is ambiguous. If sekrets does use use this filename by default, there should be a test to ensure it does. If it does not, it should, and a test should be written to ensure it does.