[Cryptech Core] Alpha firmware packaging

[Rob Austein]

Brief call for objections.

On the Novena, everything was Debian, so there was an obvious
packaging mechanism to use for all the binaries.  That's not really
the case for the Alpha.

For the Alpha, ignoring a lot of messy internals of how we build
stuff, there are basically two kinds of binary packages:

* A firmware package, containing an FPGA bitstream and images of the
  software running on the HSM's CPU (probably both .elf and .bin
  format to support both ST-LINK and DFU without requiring objcopy,
  possibly also including bootloader images); and

* A software package, containing stuff that goes the host side
  (libpkcs11.so, the RPC daemon, whatever).

For a given revision of the source code, there's only one firmware
package, but there may be a lot of software packages (OS, CPU
architecture, etc).  I am skipping slightly over a lot of nasty
details of the build system here, because this message is about the
result from the user's standpoint, not the system that produces it.

The host side software package should use whatever packaging makes
sense for that platform: .deb, Homebrew, whatever.  On most platforms
we're likely to support there's an obvious format, we just use it.

There isn't really any single obvious format for the firmware package.
Requiring a separate firmware package for each host system seems
wrong, as does the degenerate case of only allowing firmware upgrades
from Debian-family systems, so I don't really want to tie the firmware
packaging to any particular platform's native packaging system.

Most of our upload software is already Python, and the bits that
aren't yet (the stuff for uploading via an ST-LINK) may end also end
up using Python (right now it's a shell script, but the maze of
configuration possibilities for openocd (multiple operating systems,
multiple openocd releases, multiple st-link programmer models) is
starting to get out of hand, and it would probably be simpler to sort
this out in Python than in a shell script).  So I'm thinking that the
simplest thing here would just be to use a boring archive format that
Python already supports out of the box.  Therefore, my current plan is
to package the firmware binaries in a plain old compressed tarball.

Whether to include the scripts necessary to use the firmware package
in the base software package or put those in a separate developer's
package is an open question: I might just put them all in one package
for now for simplicity, but I don't feel strongly about it.  Whichever
software package includes scripts for dealing with the firmware would
also have the runtime dependency hooks to pull in whatever external
packages we need to use the firmware tarball (eg, openocd).

The firmware tarball should probably also contain a signed manifest: a
text file listing names and SHA-256 digests of the other content of
the tarfile, signed by the same PGP key that signs the APT repository,
commits to the Homebrew repository, etc.  There are other ways to
slice this, but I think a single signed manifest is simplest overall.

The firmware tarball may also contain a bit of additional meta-data in
whatever format seems simplest (read: encoded in some boring format
that Python can read out of the box, eg, JSON), but that's basically
it.  The signed manifest and the meta-data might end up being the same
file, or not, details to be worked out.

If anybody strenuously objects to this plan, holler, soon.