Port checkbox-certification-server on top of plainbox

checkbox-certification-server is a set of plugins, whitelists and
configurations for checkbox that define the tests to be performed for
server certification.

It has a few characteristics that make it a good candidate to start
using the new plainbox testing runner/engine. (Find a link to the
plainbox blueprint for a quick introduction):
- It's usually run only in very controlled environments
- Usually run by a trained technician who can be relied on to report and
  help diagnose any problems.
- Most of the tests are automated, a few manual ones ask simple
  questions that don't require complex interactions.
- At the end, it should submit the results to the certification website
  and output a local XML report. (Do we want to include outputting HTML
  here?)

Some components are missing for plainbox to fill this role. A user
interface and a secure way of running root-level jobs are examples.

This blueprint should result in a package that can be installed and a binary that can be run, to execute the server certification test suite, with a simple UI to ask the user for test verifications, and that can at the end submit results to the certification web site as well as output a locally-openable report, in XML or preferrably HTML.

Tackling the work needed to run these tests would carry the following
benefits:

- Creation of a prototype using the plainbox libraries, toolset and
  architecture to build an actual, user-interactive application results
  in a better understanding of Plainbox architecture, so developers get
  the experience needed to tackle more difficult developments (such as
  an eventual end-user-oriented desktop testing app based on plainbox)

- Use of a better-documented, more robust and better tested engine for
  certification tests.

- End user (i.e. testers) benefit from having a more robust, simpler
  tool. It's also faster and easier to adapt to their requests and
  needs.

- Developers benefit from having plainbox as the testing core, since
  behavior changes or improvements are easier to test and implement,
  and plainbox makes test development and debugging easier.

- The work which will be potentially needed to organize and repackage
  tests, even if it's only discussed during the 3-month cycle, will
  enable better separation of checkbox tests and dependencies, which is
  already being requested by some of our other efforts (cloud testing,
  checkbox in Ubuntu server)

Topics to consider:
    - urwid as possible ui?
      Checkbox already abstracted the UIs, providing a simple 'API' for
      UI classes to implement, this made adding new UIs potentially
      simple. However, care needs to be taken with the data structures
      that are sent back and forth (see a few bugs on the QT ui that
      stem from assuming data is in one format (e.g. dictionary) and
      then receiving something else (some missing keys, or a list)).

      Also, this abstraction limited the possibilities of the UI, which
      is one of checkbox's shortcomings that plainbox aims to remedy.

      So while some care should be taken to make the UI code as
      pluggable as possible, I think part of the emphasis should be
      instad in making the plainbox libraries easy to use from whichever
      UI design we choose to implement.