Use orange "united" theme from bootswatch

To match the orange design of the appliance.

TODO: Better color match (edit the bootswatch less/sass sources not the
css).

The theme is MIT licensed.
Navbar orange is lighter to match stb-tester appliance front panel

Generated with:

    git clone https://github.com/thomaspark/bootswatch.git
    cd bootswatch
    npm install
    (cd ~ && npm install grunt-cli)
    sed -i -e 's/^@brand-primary:.*/@brand-primary: #f77f00;/' \
           -e 's/^@link-color:.*/@link-color: #d70;/'
    ~/.npm/grunt-cli/0.1.13/package/bin/grunt swatch:united
    cp united/bootstrap.css ...
Remove angular-seed's "app-version" directive

This isn't part of the Angular framework itself, but something added by
"angular-seed", which is an Angular app template. I thought it was a DRY
way of somehow taking the app version from package.json, but it turns
out that it's just to let you hardcode your app version in "version.js"
instead of in "index.html", and I don't need all those lines of code and
6 files just to do that.
Remove IE-specific stuff that came from angular-seed

We don't test on IE so might as well not pretend to support it.

I don't really understand what this did, but I don't see how it was
correct -- you'd get <html ng-app="myApp"> if you were using IE, but no
<html> element at all if you weren't!? The "ng-app" is fairly crucial to
Angular, I would have thought.

modernizr.js provides feature detection ("does this browser support
html5 feature xyz?") but it doesn't actually "modernize" the browser by
implementing the missing functionality; it provides a "Modernizr" object
that you can query ("if (Modernizr.video.web) ..."). There are no
references to "Modernizr" anywhere in the codebase, so I'm removing this
too.
Default route is "automated tests", not "manual control"

This is probably what you want to do most of the time: Kick off a test
run.
Consolidate routing configuration into app.js

I find this much clearer than the existing layout, which came from the
"angular seed" template. I see "app.js" as the part that glues all the
other components together. Hopefully the controllers will be quite
minimal, but if not I can always split them out into their own files
later.
Cleanup: Rename controllers from xCtrl -> xController

According to ng-book.com:

> It is considered a best-practice to name our controllers as
> [Name]Controller, rather than [Name]Ctrl.

Also, the "[function...]" syntax doesn't seem to work once I actually
try to inject something (in the next commit), so I'm removing the
brackets (they came from angular-seed).
Add README with description, license undecided, dev instructions
Show current branch (hardcoded to master) and sha (polled from back-end)

All the logic is in the controller; I'll eventually pull it out into an
angular Service or something.

I thought about putting the `$timeout(updateSha, 1000)` inside the
`finally` part of a `try...finally`, but there isn't actually much
that can go wrong; if `data` doesn't have a `sha` attribute then
`data.sha` is `undefined`, not an exception as in other languages.
Test that test-pack branch sha is displayed

This is an end-to-end test for the functionality added in the previous
commit.

You have to manually start the backend before you run the test with
`npm run protractor`. It will automatically launch an instance of
Chromium and control it via WebDriver.

Protractor is the end-to-end test runner installed by angular-seed,
and it's the test runner recommended in the Angular tutorial.[1]

If we need more flexibility in future[2] we might consider writing tests
in python using the Selenium (WebDriver) python bindings. I'm also
committing "notes.md" with what I've figured out so far to do that.
But at least this is testing the real javascript code in a real browser
against the real back-end service.

[1] https://docs.angularjs.org/tutorial/step_03#running-end-to-end-tests-with-protractor

[2] For example, test that the sha is updated in the Web UI when you
    push a new commit to the git repo -- that's not something I intend
    to script from the javascript test code.
Use $interval, not $timeout, to poll backend

To allow end-to-end testing with Protractor. See "Waiting for Page
Synchronization" at
https://github.com/angular/protractor/blob/fcd973b/docs/timeouts.md
Limit sha display to 7 digits

To keep the UI neater.
List available tests to run, in a multi-select box

Note that we only re-fetch the list of tests from the back-end if the
sha has changed, because for the back-end this can be relatively
expensive to generate (grepping all the source files in the test-pack
repo).

I had to use the Promise's `then` instead of `success` so that I could
chain more Promises.

Note that `ng-model="selectedTests"` means that in the Controller,
`$scope.selectedTests` will contain the selected values.
Tests select-box uses test name, not array index, as <option> value

Before:

    <select>
      <option value="0">tests/example_tests.py::test_1</option>
    </select>

After:

    <select>
      <option value="tests/example_tests.py::test_1"></option>
    </select>

This doesn't actually make any functional difference: In both cases, the
selections were preserved when the list of tests on the master branch
changes and the list of options is updated. According to [1] it has a
performance benefit though I admit I don't fully understand the
implications. Angular's own documentation of "track by"[2] is pretty
minimal.

[1] http://www.bennadel.com/blog/2556-using-track-by-with-ngrepeat-in-angularjs-1-2.htm
[2] https://docs.angularjs.org/api/ng/directive/select
Ignore stale responses from back-end

This addresses a hypothetical concern I have about the following race
condition:

1. Web UI thinks sha="a". Due to the regular polling, Web UI makes
   request #1 to the backend for current sha.

2. User selects a different branch from the drop-down list (this feature
   isn't currently implemented, but bear with me). Web UI sends request
   #2 (immediately) for the new branch's sha.

3. We get the response for request #2 (more quickly than the original
   request)! We update display the new sha & the new list of tests for
   the new branch.

4. Only now we receive the response for the original request #1. We
   update the display to show the original branch's sha & list of tests
   -- that is, the wrong data for the currently selected branch.

Maybe this can't actually happen, but I don't know.

A similar problem could (hypothetically) happen with the list of tests
when the branch stays the same but the sha changes:

1. The sha changes, ask for the new list of tests.
2. The sha changes again a second later, ask for the newer list of
   tests.
3. Response #2 arrives (this would require response #1 to take longer
   than a second, which is the polling interval between noticing sha
   changes; could that be possible if the test-pack git repo is
   extremely large?)
4. Response #1 arrives and sets the list of tests to the wrong tests.

Maybe a more generic approach would be to include a token or serial
number in each request to the back-end, have the back-end return it in
the response, and check that instead. Anyway I'm probably overthinking
this so I'll stop now, but I've made the change so I'll leave it in for
now.
Remove version number from vendored javascript library filenames

So that the "sourceMappingURL" --that allows the browser's developer
tools to display the original source code for a minified file-- works.

Also, use the minified version of angular -- there's no reason not to.

When I originally downloaded these files I renamed them for 2 reasons,
both of them probably misguided:

1. Self-documentation.
2. Cache busting if (when) we upgrade these libraries.

For (1), the version number is in a comment at the top of each file
anyway. For (2) we'll have to make sure we set the right caching headers
in our web server.
Remove selected tests that have disappeared

If you select a test, then someone pushed a commit that removes that
test, when the Web UI polls the back-end Angular *will* remove the test
from the <select> list, but the test will still be listed in
`$scope.selectedTests` so when we go to run the tests we'll ask for a
test that doesn't exist (and doesn't even appear in the Web UI!) and the
back-end will respond with an error.

I have tested this manually but I'm not sure how to write an automated
test for it. It'll have to be a full integration test with an actual git
push (and I don't intend to write that in javascript in the Protractor
tests!), or we need to mock out the back end (which kind of defeats the
purpose of testing it, since it's a single line of code using a
well-tested library implementation of a well-understood set operation).

I just realised that if we select a test, then someone pushes a commit
that removes it, then pushes another commit that adds it back, all while
we're still in the web interface, we might be surprised that when we
click "run" our test somehow disappeared. So I should do the
intersection when sending the list of tests to run, not before. But I'll
leave this here for now so I don't forget it when I implement the "run
test" action.

Underscore.js (`_`) is a library of functional programming helpers like
`bind`, `map`, and the one we actually use here, `intersection`.
Remove unused dependency on jQuery

This is a first for me. Hello Angular, goodbye explicit DOM
manipulation. Fingers crossed.
Refactor: branch & selectedTests belong to "newJob" model

I'm going to be adding more fields (job name, number of iterations to
run, etc) and they all belong together.
Text field for job name

The "testjob" is when you select a bunch of tests to run, and you run
them (maybe once, maybe multiple times in soak). This is in contrast to
a "testrun" which is a single run of a single test.

This "testjob name" is the directory name where the results will be
stored. Strictly speaking, it should be "results name" or "report name"
or something like that, because you can run 2 or more testjobs and have
the results combine into a single report (that is, stored under the same
directory).