Packaging process and systemd service

[zachfeldman]

Closes #47 .

This adds a very simple packaging process and systemd service file for the inputmodule-rs to run. I have it running the ledmatrix by default now but the idea is to quickly iterate on this to a more general service to take commands via dbus or similar as we've discussed!

For now, it generally works. To cut a release, run ./release.sh. It'll install fpm (https://github.com/jordansissel/fpm) if you're missing it and use it to package up the binary that cargo builds into a .deb.

Once you install the package with dpkg -i <package-name>.deb, it'll run a postinstall script to install the udev rule and it will automatically add the systemd service and start it. It should persist between reboots.

Some other things to consider:

• We may want to run release.sh as part of the build, eventually convert it to a Makefile, or eventually use something like bazel to run the build and packaging process if we want to get really fancy
• We might not want to commit the released .debs, but I included one to easily try installing it with dpkg
• We may also want to release a .rpm for RHEL-based distros eventually
• Obviously we'll need something completely separate for Windows at some point, but this is a start!

[JohnAZoidberg]

I have some suggestions:

• Let's build the package on GH Actions and not put it in the repo
• Move all release scripts into a subfolder, maybe release/
• Add trailing newlines to the end of files (I don't get why vscode doesn't do that)

[zachfeldman]

@JohnAZoidberg all good suggestions! I've implemented them all. Put the new release action into a separate .yml/action, thinking we could run it only whenever a release branch is pushed (starting in release/) or on some other trigger vs on every single build, if you'd like. We could also merge this into software.yml or firmware.yml if preferred.

[zachfeldman]

@JohnAZoidberg same question here! (Although this is currently just merging into my other branch :))