Refactor Bazel version retrieval & downloads (bazelbuild#151)

-------
Summary
-------

This change introduces dedicated interfaces to handle how Bazel versions are retrieved and downloaded.

-------
Details
-------

The new `core` package introduces interfaces that represent four kinds of repositories that store Bazel versions: `ReleaseRepo`, `CandidateRepo`, `ForkRepo` and `LastGreenRepo`. Implementations of these interfaces must provide a list of available Bazel versions, as well as a function to download a desired version.

The old main function was moved into `RunBazelisk()`, which expects implementations of these interfaces. As a result, the caller of this function can control which repositories are used.

The previously existing repositories, GitHub and GCS, are still supported since they implement the new interfaces. GitHub is used for forks, whereas GCS is used for everything else.

Moreover, the existing `BAZELISK_BASE_URL` environment variable is still supported, and overrides the repository interfaces (if set).

Finally, this change moves some utility functions into new, dedicated packages such as `httputil` (for retrieving files via HTTP), `platforms` (for determining platform specific information) and `versions` (for sorting version numbers).

----------
Motivation
----------

The idea is to turn Bazelisk into a library that supports arbitrary repositories. For example, companies might want to ship their own version of Bazelisk that fetches all Bazel binaries from their internal servers.

----------
Next steps
----------

The next PR will move `RunBazelisk()` into the `core` package so that it can be used as a pure library. I didn’t want to move it in this PR to get better code diffs.

------------------
Functional changes
------------------

Even though this is a refactoring, a functional change has been made: The previous version used GitHub as a fallback when GCS was unavailable. This is no longer the case.

As a result, the Python version now deviates from the Go version since the latter uses GCS, whereas the first uses GitHub.

This forced me to rewrite the shell test, too, since the Go tests must be less strict wrt expected versions:

Since the Go version uses GCS the fake json file written in the test is only used by the Python version.
As a result, the shell test is effectively an integration test for the Go version and requires network access. Moreover, we can no longer check for specific Bazel version in the Go test since "latest" will point at different releases over time.

We should split the test into proper Go and Python versions.

* De-duplicate repo selection logic

The first version of the PR determined which repo should be used (e.g. release vs candidate repo) in two places:
Once in bazelisk.go when the version had to be resolved, and a second time in the core module when a binary had to be downloaded.

This has now changed: core.Repositories got the new ResolveVersion() function that resolves a version label and also returns the appropriate download function.
As a result, bazelisk.go is no longer in the business of caring about versions and can simply call the download function (unless BAZELISK_BASE_URL is set, of course).

Positive side-effects:
- All version parsing / analysis was moved into the versions module.
- A lot of code from bazelisk.go could be removed.
- LastGreenRepo was renamed to CommitRepo and now supports commit hashes, too.

BUILD

@@ -47,6 +47,11 @@ go_library(
     deps = [
         "@com_github_hashicorp_go_version//:go_default_library",
         "@com_github_mitchellh_go_homedir//:go_default_library",
+        "//core",
+        "//httputil",
+        "//platforms",
+        "//repositories",
+        "//versions",
     ],
 )
 

README.md

@@ -40,6 +40,7 @@ Bazelisk currently understands the following formats for version labels:
   Previous releases can be specified via `latest-1`, `latest-2` etc.
 - A version number like `0.17.2` means that exact version of Bazel.
   It can also be a release candidate version like `0.20.0rc3`.
+- The hash of a Git commit. Please note that Bazel binaries are only available for commits that passed [Bazel CI](https://buildkite.com/bazel/bazel-bazel).
 
 Additionally, a few special version names are supported for our official releases only (these formats do not work when using a fork):
 - `last_green` refers to the Bazel binary that was built at the most recent commit that passed [Bazel CI](https://buildkite.com/bazel/bazel-bazel).