Merge lp://staging/~sinzui/juju-ci-tools/use-s3ci-to-get into lp://staging/juju-ci-tools

Use s3ci.py instead of jujuci.py.

jujuci.py is not reliable under parallel conditions. Its default
behaviour is to download artifacts from the *latest* build of a
jenkins job. The latest can be for a different build revision. This
is was caused the build-osx-client job to select the wrong tarfile.

There is a second bug in jujuci.py where it will try to get the exact
version you want, but it will only look 10 revisions back; we tested
13 yesterday!. As jenkins deletes old builds, there is no guarantee
that jujuci.py can get the artifacts.

s3ci.py does not have these limitations. There are 2 kinds of changes
that switch to s3ci.py.

1. get the juj-core tarfile, the exact tarfile, not the current one.

  build-osx-client-remote.bash
  gotestwin.py
  jenkins_build_package.py (not a test but a helper for us humans)
  tests/test_gotestwin.py

2. get buildvars.bash and source them. We do this in most scripts and
in jenkins jobs, but these scripts were skipped over the last year
    source $(s3ci.py get $revision_build build-revision buildvars.bash)

    assemble-parallel-streams.bash
    parallel-streams-job.bash
    run-osx-client.bash
    test-restricted-network