Okay! As discussed in #48, all key parties (both authors, plus the Debian maintainer) are game to try to unify on a single minica implementation. I really appreciate everybody's quick responses and flexibility.

Right now, the situation is a little confusing:

1. Googling for minica yields the jsha version.
2. Installing minica on Debian (or variants, like Ubuntu) yields the paultag version.
3. Installing minica via Homebrew (on macOS) yields the jsha version.
4. https://letsencrypt.org/docs/certificates-for-localhost/ links to the jsha version.

The biggest differences between the tools are in the command-line UI and the default filenames/flags.

In this patch, I've added a single tests.sh that exercises the basic functionality (issue a snakeoil CA and cert, trust the snakeoil CA, then use it for a TLS connection), and passes against both versions with the modification to permit domains to be specified as trailing/non-flagged arguments.

If this were to replace the existing Debian version, however, it would still technically be a breaking change for two reasons:

1. The output files for the CA and certificate pairs are different between the two utilities, and cannot be configured with flags currently. What are Debian's rules for a breaking package update like this?
2. One is licensed APL2 and one is licensed MIT, although jsha is the sole author and has offered to dual license as APL2 to address this, if needed. Does this matter for Debian packaging policy?
3. I'm game to port the remaining flags, except for "type." I don't write Go for a job and I doubt I can quickly get the client certificate option from the paultag working as a cleanroom MIT implementation, although if we can work out the licensing, I could probably do it by copy-paste.