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).