Extract all per-commit tests to self-contained scripts.

Each top-level component (and each component under providers/) can
supply a test script named "container-tests-*", to be run to test the
container.

Scripts must adhere to the following contract:

Tests are found in each component's requirements/ dir and are named
*container-tests-* Tests scripts are expected to:
 - Have a name describing what they do (e.g.
   container-tests-plainbox-unit-testing)
 - Be run from the *component's* top-level directory. This is a
   convenience to avoid a boilerplate "cd .." on every test script. So
   for 'plainbox' we do the equivalent of
   $ cd $BLAH/plainbox
   $ ./requirements/container-tests-plainbox
 - Exit 0 for success, other codes for failure
 - Write logs/debugging data to stdout and stderr.
 - Scripts can be prefixed with a number (001-container-tests-blah) to
   force a specific running order, this works within each component
   only.

All existing tests were converted to this format. Note we're not using
them yet, it's preparation to support multiple container technologies
for testing. Tests for providers that didn't have them were also added,
as the script for providers is the same for all of them. Also a test for
the checkbox-support component was added.
test-in-vagrant: Use per-component mini-scripts for testing.

This updates test-in-vagrant to look for, and use, the
previously-converted mini-scripts for testing each component.

This reduces duplication significantly and paves the way for running the
per-component tests under VM/container systems other than Vagrant, as
it'll be easier to rewrite the "run loop" once and just adapt the
startup, provisioning and shutdown parts for each container system.

Also, the test running line was updated to run commands on the vm in
$HOME.

Instead of assuming ssh into the virtual machine places me into my home
directory, explicitly reference $HOME in the commands, to make this an
absolute path. This still works because the $HOME parameter is expanded
once we are *inside* the VM so things will reference the correct
location, while being more compatible with what test-in-lxc (which will
expand $HOME to the invoking user's home, rather than that of the
container's user) will do.
"Extract all per-commit tests to self-contained scripts.
Update test-in-vagrant to look for, and use, the mini-scripts for testing each component.
    
Each top-level component (and each component under providers/) can supply a test script named "container-tests-*", to be run to test the component.

All existing tests were converted to this format and new tests were added for providers lacking them.

 [r=zkrynicki][bug=][author=roadmr]"
provision-vagrant: A few changes to support other container systems.

This is preliminary work to remove some Vagrant assumptions, to enable
using the same provisioning script with other container/virtualization
systems (particularly to add support for LXC).

- Short explanation of how the script runs
- Made CHECKBOX_TOP relocatable to the parameter the script receives,
  though we default to /vagrant if we didn't receive anything else.
  This is because test-in-lxc can place the source tree in an
  unpredictable location and provision needs to be aware of the
  location.
- Made the Vagrant sanity check conditional on $CHECKBOX_TOP being
  /vagrant.
- Modified the code to create the $HOME/src symlink to account for
  different container/VM engines since lxc behavior is different from
  Vagrant, this is explained in the comment for the last section of
  the script.
test-in-lxc.sh: Added script to perform per-commit testing with LXC.

This mimics test-in-vagrant.sh, but using an LXC container instead of a
Vagrant/Virtualbox virtual machine.

The tests run once the vm/container is up are the same miniscripts run
by test-in-vagrant, the "run loop" is identical except that they're run
using a different command (lxc-attach instead of vagrant ssh).

Testing under LXC is not much faster than Vagrant, since the bulk of the
time is spent in the provisioning phase (downloading + installing
packages) which doesn't benefit from LXC's faster creation and startup
times, but a crucial advantage is that it should be lighter on resources
and run on a cloud machine instance without nested hardware
virtualization support. The script includes a KEEP_DATA variable which
can be left blank to use memory-backed overlayfs for the ephemeral
container (this is very fast), or set to --keep-data to use a dir-backed
overlayfs, which is slower but better for low-memory environments. 2 GB
RAM are needed to use memory, and I suggest 4 if possible.

A disadvantage is that LXC commands need to be run with sudo, which
requires a bit more configuration than Vagrant. Required sudo
configuration is described at the top of the script.

Tests are referenced to $HOME, which in the LXC container is *not* the
$HOME of the logged-in user, but the $HOME inherited from the invoking
environment. However this works because the provisioning script creates
the $HOME/src symlink, similarly, referencing the invoking $HOME.  This
test-in-lxc behavior regarding $HOME is a bit strange but consistent and
it works as long as --keep-env is used.
mention LXC in the documentation