Add basic http proxy & hypnotoad support.

For now, doesn't add any xss headers.

---

Note that trying to run with plackup seems to generate mangled incoming
requests.

morbo/hypnotoad show the request as

    GET /path/file.txt Some user agent

along with a "Host: example.com" http header.

But plackup, with or without -s Starman shows:

    GET /http://example.com/path/file.txt Some user agent

it has the same, correct Host header, but the mangled path above borks us.

---

I suspect we need to do more header mangling, not least stripping the
Mojolicious server header from the response we send back.  For now, harmless
enough, but will want fixing in due course.  $debt++
Make the app's base configurable.

---

Can't find a better way to get the parent (lib/Vulture.pm) to stash a value the
templates can see.  $self->stash() seems to get cleared out.

Using a function works, but it's ugly.

---

In theory, the only page that *need* to be served by the app, and done when in
"proxy" mode, is the one that first loads the initial client test page, that
will contain the iframe with the target test url/page.  Required so as to get
around the XSS restrictions.

We could then choose to hardwire all api calls to, say,
http://testing.example.com

And ensure the proxy is clever enough to (a) intercept that domain, and (b)
re-direct the request back to itself.

However I think we'd still want that intercept domain to be configurable, and
for now, simply making all local request paths use some configurably rare
prefix ought to suffice.

What you don't want is:

    $api_base/some/local/api/path

matching a legit request that we instead should be proxypassing.
Kill page/bar and re-implement as /client/, with proper api_base suport
Use correct url on test/edit page (iframe & input)

And add/update the test data files, including the new 123.txt.json
Properly execute tests, in frame, in client hq

The very basics of having the test "client" which polls for work load the
correct url into the iframe and inject the javascript code to run, then log the
result.

This is exceedingly rough n ready & needs plenty polish, but it works :)
Use FindBin to figure out our location, rather than hardwired absolute path
ugly, embarrassing dirty hack to avoid proxying to ourselves.

it causes a tailspin and we end up trying to proxy a request for a non-existant
page on the local app, achieved by, say:

    morbo --listen "http://192.168.0.100:8888"

then, in a browser using

    http://192.168.0.100:8888

as the proxy, make a request for:

    http://192.168.0.100:8888/blah

be warned : you should eventually get the server quitting on you, else try
kill -9
Auto set test id on edit, and allow creation of new tests
Ensure we unload previous iframe on load handlers

Also, confirm via dialog when trying to close the client/hq page.

Reloading resets the session id.
Allow tests to execute in parent & in iframe context

We want to be able to run script in the context of the parent, test-app, page.

And also then inject tests into the iframe to run.

Broadly, this would allow:

    // 1. Load page into iframe
    // 2. Run tests to ensure some link/form exists
    // 3. Click on link or submit a form, causing iframe to (re)load new page.
    // 4. Run more tests inside the iframe, this time on the new page.

Aka:

    // This will run in the scope of the "parent" page.
    // Either http://dev.www.theregister.co.uk/TESTING/test/edit/123
    // or     http://dev.www.theregister.co.uk/TESTING/client/
    $('#log').append('<p>foo</p>');

    // This will get injected into the iframe.  It is blocking.
    do_test(function() {
        $('#right-col').toggle();
        alert(1);
    });

    // Once the above do_test() code has run, within the iframe, control
    // returns to the parent page context.
    $('#log').append('<p>foo</p>');

    // more do_test(function() { ... }) stuff could go here.
Add <div id=log> to test/edit to match client hq
Worked example of do_test() sugar
Add db client cols for browser/os/device details

We're denormally storing this, as it's calculated from the user agent string we
also store.  But it's going to be useful when we come to want to produce
aggregate reports.
Provide sugar to inject jquery into iframe

Then called like:

    // with_jquery is like do_test() except it first:
    // - Loads jQuery into the iframe
    // - waits for it to load
    // - then does further tests.

    with_jquery(function() {
        do_test(function() {
            console.log('1' + $('body').html());
        });
        do_test(function() {
            console.log('2' + $('body').html());
        });
    });
Track each test's result & log individually in DB

Rather than client_task.result being a single string value, we instead:

    - each is/isnt/ok test log's the result in test_log js array
    - after running a "task" in the browser, send test_log back when marking
      the task done.
    - store each result in a client_task_result row

For now, there is no webby UI to view these, but that's up next :)

Until then, poke around in the DB.
Merge branch 'proxy'