Remove dependency on Maven binary

[jin]

Consider using another fetching mechanism to download AARs. With Skylark maven_aar, downloads are failing randomly on the CI: bazelbuild/bazel#4979 (comment)

Since we know the exact repository where the files are downloaded from, possible candidates are:

1. http_file
2. a variant of java_import_external for aar_import

On top of not having maven as a dependency, these two rules use the more robust HttpDownloader underneath, which also supports multiple URLs for fallback.

[jin]

Prototype: https://github.com/jin/gmaven_rules/commit/954658d4fdc22231fcc7584aa99bbfc5727499ba

The new gmaven.bzl will contain generated targets like this:

aar_import_external(
    name = "com_android_support_test_espresso_espresso_core_3_0_1",
    aar_urls = [
        "https://dl.google.com/dl/android/maven2/com/android/support/test/espresso/espresso-core/3.0.1/espresso-core-3.0.1.aar",
    ],
    aar_sha256 = "dbca1a46db203a7ef12aa7cea37e5d5345900f83401b32d5f60f220991290948",
    licenses = ["notice"],  # Apache
    deps = [
        # GMaven does not have org_hamcrest_hamcrest_integration_1_3
        '@com_android_support_test_runner_1_0_1//aar',
        # GMaven does not have com_google_code_findbugs_jsr305_2_0_1
        # GMaven does not have javax_inject_javax_inject_1
        '@com_android_support_test_rules_1_0_1//aar',
        # GMaven does not have com_squareup_javawriter_2_1_1
        # GMaven does not have org_hamcrest_hamcrest_library_1_3
        '@com_android_support_test_espresso_espresso_idling_resource_3_0_1//aar',
    ],
)

Perks:

1. no maven dependency
2. sha256 validation
3. multiple URLs
4. ability to generate java_import_external targets automatically for jar deps
5. ability to set default repositories for generated non-Google Maven targets
6. licenses, srcjar support

cc @ahumesky, @slinzner, WDYT?

[jin]

The aar_import_external rule can be bundled in this repository to decouple from the Bazel release cycle for now, and upstreamed into Bazel later.