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.