Add Nix flake

[hawkw]

This commit adds a Nix flake for building Humility for Nix users, providing a dev environment with build dependencies for use with nix develop or direnv, and (on NixOS) configuring udev rules to allow all debug probes supported by probe-rs. Parts of this flake --- in particular, the code for cross-compiling for multiple targets --- are based on code written by @faithanalog.

What The Flake Provides

The flake provides the following:

• Packages for humility (for the host platform), as well as humility-aarch64 and humility-armv7l for cross-compiling for ARM linux environments. These were in @faithanalog's config as I believe she's got dev boards hooked up to a Raspberry Pi or something that she SSHes into, but would like to build Humility on her dev machine for the Pi target.
• The Linux packages contains the canonical udev rules published by probe-rs, allowing NixOS users to add

   services.udev.packages = [ pkgs.humility ];

  to their configuration.nix to allow all the debug probes that probe-rs supports to be run by non-root users. This config is fetched from the probe-rs/website Git repository, so if upstream adds new supported probes, we can pick up their changes.
• A flake app for use with nix run, which runs a Humility command.
• A dev shell including Humility's build time dependencies, which can be used with nix develop or direnv
• A NixOS module programs.humility which can be used by NixOS users to add Humility to the system's packages, add the udev rules, and add user account(s) to the plugdev group to allow access to debug probes.

On Checking In Nix Configurations

I understand that checking in configurations that are specific to a package manager/distro that not everyone uses may be controversial. And, if folks don't want Nix configs in the main Humility repo, that's understandable, and there are alternative options for Nix users to build Humility --- we can also have a Nix flake in a separate repo that fetches the Humility sources from Git. However, checking in this flake to the Humility repo has some meaningful advantages for Nix users:

1. It allows the Nix build environment for packaging Humility to be used as a dev environment for direnv or nix-develop. If the Nix configuration is not in the source tree, it can't easily be used with direnv. Of course, Nix users can have their own dev environment that isn't checked in. However, this would no longer be the same build environment definition that would be used for building a Humility nix package, meaning that there is the potential for drift between individual contributors' dev environments and the canonical build environment.
2. I'd like to eventually set up publishing to FlakeHub on CI when new release tags are pushed to the repo, requiring an in-repo Nix flake.
3. I know at least a few folks at Oxide are Nix users (at the very least, myself and @faithanalog), and it seems nice to have a canonical configuration in the repository rather than requiring folks to write their own (potentially differing in minor ways) whenever a NixOS user wants to build or contribute to Humility.

If this rationale isn't convincing, that's okay, and I'm happy to close this PR. :)

[faithanalog]

I like the chunky comments for making the different outputs distinct.

I'm assuming that if we wanted to FlakeHub it, we'd need to proactively keep the flake up to date. Right now needing to manually update the output hashes of the git dependencies. I have heard tell of something that might be able to automate updates to them but I don't remember what it is- I can go asking around. I know that I can PR updates to it as necessary but I only pay attention when I'm updating humility on my jumpbox pi. Maybe you'd run into it frequently enough to keep that up to date though.

[hawkw]

I'm assuming that if we wanted to FlakeHub it, we'd need to proactively keep the flake up to date. Right now needing to manually update the output hashes of the git dependencies. I have heard tell of something that might be able to automate updates to them but I don't remember what it is- I can go asking around.

Yeah, figuring this out is why I didn't include publishing in this PR...having to update those hashes manually is unfortunate. Fortunately, a majority of them haven't changed since you published your blog post a while ago. So, the amount of dependency churn isn't too bad...