Adding a timing mode that records test execution times per host.

This is for catching regressions (or improvements :) that let
execution times divert significantly. I've been playing with various
ways for doing this for a while, it's tricky because execution times
can differ between runs quite a bit. This model seems to work best so
far:

    - Tests that are to be measured are marked individually with
      @TEST-MEASURE=TIME (that way one can pick the tests where it
      makes sense, which are usually longer running ones like Bro's
      external tests).

    - Timing baselines are kept separately from the existing
      baselines, and on a per host-basis, in Baseline/_Timing. They
      are indexed with a unique host identifier so that we don't
      compare apples and oranges. A timing baseline gets created with
      the new -T option. If no timing baseline exists for the host
      btest is running on, time measurements are ignored and the test
      gets executed as usual.

      (I'm still undecided on whether we should commit timing
      baselines to the upstream repository for hosts people normally
      run their tests on (including Jenkins), or just keep the files
      around locally.)

    - If a timing baseline exists and a new test execution deviates by
      more than 1% (default), that counts as a failed test.

    - Finally, because just measuring actualy execution *time* is
      pretty unreliable, btest instead measures executed CPU
      instructions. That however needs non-standard platform support.
      Currently, it works only on Linux where it leverages "perf". On
      other platforms, or if perf is not installed, timing
      measurements are silently skipped.

Further suggestions welcome. I'll play with this more, and also need
to see if there's a perf-equivalent for at least Mac OS and FreeBSD.
Always showing timing diffs with test status if we have a timing
baseline.