Implement new results storage and pinging system

* Drop redundant `run_useragent.runs` column.
  This was duplicating the role of `run_useragent.completed`.

  The purpose of the duplicate row was to keep track of runs that
  have finished running, but need (or don't need) additional re-runs.

  This is now done using the 'status' and completed/max columns.

  run_useragent.status: Re-defined.

* Replace `run_client` table with `runresults` table.

  Main difference is that the `runresults` has its own identifier
  column which means it can be accessed directly.

  Also rows from this table are to be never removed, not even when
  a run is re-run, wiped, reset or cleaned up.

  A link to /result/123 is to be considered permanent.

  Of course they can be unlinked from the run_useragent table (i.e.
  when a job is reset, that field is NULLed, and if a better re-run
  is saved, it overwrites that link with the new one). But this data
  is preserved.

  This also improves performance in several places by not having to do
  a full table scan of run_client and client to find all entries for
  a certain user_agent (which was very slow).

  Uses a `store_token` to control ability to save results into the
  stub row. Previously clients could basically pass anything to
  SaverunAction, and screw up stats. This whole in the system is now
  fixed.

  Update dbUpdate.php: Use run_client as check for 1.0.0
  Although both `useragents` and `run_client` are good checks to
  detect pre-1.0.0, using the latter as a check allows testers of the
  alpha versions before this commit to be notified as well.

* New `run_useragents.results_id` column.
  No longer "guess" which belongs to which (by looking up the run_id
  and all possible client_id's), but tie them together right there.

* Implement ping system
 - Clients ping every (conf->client->pingTime) seconds through AJAX.
   We use this to determine whether the client is still alive.
   Up until now we used a combination of connectTime and "last time
   a run was saved" to determine client connection. Which means you
   couldn't consider a client to be "gone" without also requiring that
   runs may run for a very long time.

   Now the pingTime can be set to 30 seconds and the runTimeout
   (maximum execution time) to 5 minutes. And a run can perfectly be
   allowed to take 5 minutes, but if the client is gone after anywhere
   in less than 5 minutes (e.g. 2 seconds, 3 minutes whatever) the run
   can be reset earlier and the client considered "offline" much
   faster.

   This should speed up things on swarm.jquery.org in case there is a
   run causing a browser freeze of whatever. Because we can allow a
   run to run for 5 minutes while being able to assume "disconnection"
   much earlier than that.

* Moved confUpdate from getrun/saverun to pingAction.

* Removed properties:
 - JobAction: runRuns, runMax
   No longer relevant, don't exist any more.

* New "Result" page which shows navigation to results from other
  browsers for the same run.

  As well as some generic data and the client ID / username.
  and displays runID/jobID pair as well.
  (previously this was next to impossible to extract after the run was
  saved).

  Now serving the runresults html through an iframe instead of
  directly to the client. Getting it directly is still possible
  through query parameter "?raw=".

  State constants are defined in ResultAction class as static
  members named ResultAction::$STATE_*. Using these in PHP instead of
  using the primitive number values directly
  (and ending up clarifying code with comments explaining the numbers,
  again, and again..)

  Updated logic to show a link to the Result report even if the test
  is still in progress or if it timed out (not just if it passed
  or completed with failures).

  We store the report either way, so we might as well show it.

  Previously this was quite annoying when the test was infinitely
  "in progress" or timed out, there was no link and nothing to see.
  Now it links to the report and at least shows the data we have,
  can help solving problems.