Update server with task partial results

Rather than waiting until the entire task, and all tests, have completed, then
updating the server with all results.

Instead, update the server at the end of each do_test() block.  This allows you
to write a single task, with multiple tests and keep the server updated with
your progress.  Intended for tasks that contain many tests that might take a
while to complete.

Also:

- rename start_tests() to clear_log()
- move send_result() from hq.html.tx to the more global _page.tx
Small improvements to task report page : show test results
Reset 'loading' after injecting jquery into iframe
rm todo comments and add one about defaults
Rename sessionid and guid to client_id and app_id

noop (hopefully), just moving towards a better naming convention for
various concepts.
Rename ClientTask as Job

noop (hopefuly), just renaming things.
Rename Task as Run
Rename Tests as Tasks
Rename do_test/task js func as work()
Rename with_jquery(code) to using('jquery', code)
Avoid undef warning when calling work() from task/edit
Simplify & improve output of HQ page.

Rather than join -> work, and stop -> leave, I've condensed those down into
just Start and Stop.

Also, reduce the log noise, and make a single status line that contains
connected + working state, plus ident.

Then, automatically update status every 5 minutes while connected/working.

And slightly better date/time format.

And keyboard shortcuts for the buttons :)

Also include the client id in the json response to "get/state";
Add Test::More inspired sugar: is, isnt, like, unlike, diag, pass, fail, hasClass

    var text = 'Data Centre';
    top.diag("Text is '" + text + "'");
    top.is(text, 'Data Centre', 'Text is GB English');
    top.isnt(text, 'Data Center', 'Text is not American');
    top.like(text, /Data/, 'Text contains Data');
    top.unlike(text, /Center/, 'Text has no US spelling');
    top.hasClass('#foo div:first', 'nav', 'First #foo div has nav class');
Add wiki links and tweak intro text on README.md
Add epoch timestamp and state col to job_result

state is denormally inferred from the start of the result line text.  We can
probably do better in due course, by no storing an array of log lines, but
rather an array of objects, each of which has a state, test_name and
'pretty_test_name' properties.
API hook to query a run

curl http://127.0.0.1:3000/TESTING/api/client/run/1

{
   "run" : {
      "jobs" : [
         {
            "client_id" : 1,
            "run_id" : 1,
            "state" : "complete",
            "created_at" : 1353539951,
            "started_at" : 1353539951,
            "id" : "1",
            "finished_at" : 1353539953,
            "results" : [
               {
                  "epoch" : 1353539953,
                  "job_id" : 1,
                  "id" : "2",
                  "state" : "not ok",
                  "result" : "not ok All #right-col children 300 pixel wide"
               },
               {
                  "epoch" : 1353539953,
                  "job_id" : 1,
                  "id" : "1",
                  "state" : "ok",
                  "result" : "ok Visible (non adblocked) #right-col children 300 pixel wide"
               }
            ]
         }
      ],
      "created_at" : 1353539951,
      "started_at" : "1353539951",
      "id" : "1",
      "task_id" : 224,
      "finished_at" : 1353539953,
      "state" : "complete"
   }
}
Improve TAP output format

Based on http://en.wikipedia.org/wiki/Test_Anything_Protocol

The numbers are going to require further meddling when reported in aggregate
for multiple clients in the same run.
Fail early if trying to run a test and no active clients exist
Reuse existing variables rather than re-calculating
Add blocking support to api/run/$TASK_ID

Running a task via:

    api/run/1

will run task 1 as before, returning immediately with the run id, that you can
then poll via

    client/run/1
    api/client/run/1

To block:

    api/run/1?block=1

will run task 1, but will not return until either the task/run has completed,
or a timeout occurs.  On success, a rich json result, containing the same data
as client/run/1

Or for TAP:

    api/run/1?block=1&tap=1

will block and return something approaching TAP format output.