spec: propose mapping of a hardware device

After an offline discussion with @vbatts & @jonboulle wanted to begin the discussion of support for hardware devices and beginning to map out what that looks like. To give the reader three examples we'll use software defined radios and NTP (which, in this day and age is increasingly a SDR), and USB Armory - a hardware module with the ability to be used as an authentication token.

In the case of software defined radios a user has a device with a chipset when can change the tuned frequency through the use of software. One no longer needs a specific device built to listen on a frequency (in this example we'll use APRS) but can write a piece of code which tunes the chipset to 144.390 MHz and can receive packets over the air. This allows for receiving weather data, transmission of short text data, and telemetry from moving craft (in the past I have used this for transmission of telemetry data from a space blimp). Many pieces of SDR software have complex setup requirements which could greatly be simplified through the use of containers. Going further being able to have multiple containers on a host where each is connected to a different hardware device would allow for isolators guarantee a higher degree of stability from buggy software and potentially complex processing blocks (in the case of GNURadio).

In the more general case an enterprise may utilize a combination of GPS and GPRS hardware devices with NTP to run a series of stratum one clocks to guarantee strict timing precision for the use of encryption and routing protocols.

In the case of USB Armory an organization could store secrets in the device and then pass it directly into a container where only the container could unlock the device.

Also, as there is still a limited discussion about this I get the sense that many folks are still looking at this with an eye towards web based workloads. I think that In proceeding forward there are three primary considerations:

1. Specification of a generic format for defining the hardware requirements of a container
2. Specification of the mechanism for providing that device to the container from the host
3. Specification of the mechanism for consumption of a device provided from the host to the container

I could foresee an initial discussion of this starting with one of two patterns: Use of major/minor device which should work on all POSIX compliant systems or use of UDEV rules which places a dependency on UDEV which some users will find undesirable or impossible to implement (I could make a guess about @mpasternacki here.)