Allocates guest MAC addresses via a next item query

[bnaecker]

• Provides random base address within the guest-visible range of
  A8:40:25:F0:00:00-A8:40:25:FE:FF:FF.
• Switch the database representation of MAC addresses in the
  network_interface table from a string to INT8. The string
  representation is human-readable, but doesn't allow any other
  operations on it (such as addition). There's also no native
  MACADDR support in CRDB, so we don't lose much by switching to a new
  repr. Any client code needs to parse/interpret the value anyway, and a
  byte-representation in some ways is more natural or obvious.
• Adds a NextItem query for generating a random guest MAC address. This
  is the upshot of the change to an integer, that we can add to it and
  thus use the NextItem query machinery.
• Adds a variant of the NetworkInterfaceError for detecting MAC
  address exhaustion.

[bnaecker]

This PR should resolve both #959 and #963. It uses the new NextItem machinery to select an available, random MAC address for guest NICs within the reserved portion of the range. This allows us to both preclude selection of the MAC reserved for the OPTE virtual gateway (or other system services), and avoid conflict, without a retry loop.

The cost we pay for this is a change in the database representation. Previously we stored addresses as strings, e.g., a8:25:40:f4:01:02. That's nice and human-friendly, but it doesn't work in a NextItem query, which requires a type we can add integers to. This PR changes that to a INT8, using the 6 least-significant bytes to store the octets of the MAC. (Note that it's always big-endian.)

I've also added a new variant of the NetworkInterfaceError that detects MAC address exhaustion. I tested that by artificially restricting the range of possible MACs and seeing this when provisioning:

bnaecker@feldspar : ~/cli $ ./target/debug/oxide instance create -o o -p p -D "vm0" --hostname vm0 -m $((1024 * 1024 * 1024)) -c 4 vm4
✘ Invalid request: No available MAC addresses for interface

It's likely we'll hit other limits before this one, but I'd like to have an explicit check in any case.