[WIP][POC] Starlark implementation of kt_android_* rules

[mauriciogg]

This PR is intended to be a proof of concept of integrating rules_kotlin with the Starlark version for rules_android. This PR uses the pre-alpha version of rules_android with some additional fixes to integrate with rules_kotlin here (Note that rules_android is not officially supported and this is just a private fork).

The most interesting bits of these PR are in the android.bzl, android_impl.bzl and android_resources.bzl files. Additionally, examples/android contains an example usage of android_application with a very simple configuration.

There are several benefits of integrating with rules_android:

• kt_android_* rules can be implemented natively in this repo without the use of sandwich rules. This means that ${target}_kt targets no longer exist only the original ${target}
• Decoupled from Bazel binary. Enhancements to the resource processing (the main pice of functionality we use from rules_android here) pipeline can happen without needing to wait for Bazel updates.
• Enable use of app bundles and dynamic features via android_application rule. This rule will not be implemented in native Bazel.
• Future proofing rules_kotlin- native rules_android will be deprecated at some point.

This PR does the following:

• Implements kt_android_library and kt_android_local_test by using the resource processing pipeline implemented by rules_android. This enables these targets to provide the StarlarkAndroidResourcesInfo provider which is the provider collected by the Starlark rules and need in order to use the android_application rule.
• Toggles the usage of starlark rules_android in rules_jvm_external by setting use_starlark_android_rules = True in maven_install
• Migrates the examples to load the pre-alpha rules_android.
• Adds an android_application target that generates an App Bundle under examples/android

The performance of this implementation is very close to the current implementation (tested on our internal repo). The build graph is mostly the same as what currently exist. In addition multiplex workers are enabled for the resources actions (same as current implementation). We are experimentally building our Android project internally using this implementation and all our builds and tests are green, but your milage may vary (fixes were tailored to problems I encountered in our repo).

The main objective of this PR is to start the conversation towards an official migration, move the rules_android (my fork) repo (ideally bazelbuild/rules_android) to a more official home and create a shared stewardship of the repo.

Some caveats

• This was only tested with our internal repo so YMMV. The upstream rules_android repo is not yet officially supported. See https://github.com/bazelbuild/bazel/issues/5354
• dynamic features work only with targets that contain native libs and assets (not sources and not resources)
• fetching sources in maven_install is not possible (this is a simple filename extension issue)
• depending on concrete files from a external maven targets will fail since for whatever reason the visibility of those artifacts is private when using starlak rules_android`
• Changes are required in the intellij plugin for these rules to play nice with the IDE

[Bencodes]

We should probably cut a new release of rules_kotlin before we land this PR so that there's something stable out there in case this has bugs.

[nkoroste]

fyi @ahumesky - it will need some of the fixes from https://github.com/bazelbuild/rules_android/pulls