--experimental_check_desugar_deps (on by default) breaks Android builds with remote execution

### Description of the problem / feature request:

When building an `android_binary` using remote execution and without explicitly passing `--noexperimental_check_desugar_deps`, the build will fail with this error:

singlejar_cc_bin: external/remote_java_tools_linux/java_tools/src/tools/singlejar/singlejar_main.cc:27: Desugar checking not currently supported in Bazel.

### Feature requests: what underlying problem are you trying to solve with this feature?

N/A

### Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Download and extract [repro.zip]. Run

bazel build //subject:app

Observe that the application builds correctly. Then try building it remotely:

bazel build --config=remote --remote_instance_name=projects//instances/default_instance //subject:app

(Replacing `` with a Google Cloud project ID that has Remote Build Execution set up. This can also be reproduced without RBE by using a local `@io_bazel//src/tools/remote:worker` by passing the appropriate flags.) Observe the following failure:

ERROR: <...>/repro/subject/BUILD:1:1: Building deploy jar subject/app_deploy.jar failed (Exit 1)
singlejar_cc_bin: external/remote_java_tools_linux/java_tools/src/tools/singlejar/singlejar_main.cc:27: Desugar checking not currently supported in Bazel.
Target //subject:app failed to build

Now try adding `--noexperimental_check_desugar_deps` to the command line. Observe that it succeeds.

### What operating system are you running Bazel on?

Ubuntu 16.04.6 LTS

### What's the output of `bazel info release`?

release 0.29.0

### If `bazel info release` returns "development version" or "(@non-git)", tell us how you built Bazel.

N/A

### What's the output of `git remote get-url origin ; git rev-parse master ; git rev-parse HEAD` ?

N/A (Bazel binary from GitHub releases; repro repository [provided as ZIP][repro.zip] above)

### Have you found anything relevant by searching the web?

Yes. This flag was flipped in Bazel 0.21 and was mentioned [in the release notes](https://blog.bazel.build/2018/12/19/bazel-0.21.html):

> # Android
>
> * [`--experimental_check_desugar_deps`](https://docs.bazel.build/versions/master/command-line-reference.html#flag--experimental_check_desugar_deps) is enabled by default. This flag rules out several types of invalid Android builds at compile-time. Note that this is incompatible with remote Android builds, so you can disable it with `--noexperimental_check_desugar_deps`.

There is also a comment in the code that references what I assume to be a Google-internal issue, b/67733424, which I'm guessing has about the same information as in this issue, but I can't see it because I'm not a Googler and no public bugs were ever filed on this issue as far as I can tell.

### Any other information, logs, or outputs that you want to share?

It was unclear to me why `singlejar_main.cc` and `singlejar_local_main.cc` both existed and why the remote one doesn't support desugar checking -- naïvely it seems like it would be sufficient to have only one, and have it be used both locally and remotely. After some investigation, I think I've figured out why it is the way it is. Local builds can use a pre-built `singlejar`, which can incur whatever dependencies it wants, as it's built at the time Bazel is built. Remote builds don't actually use a singlejar included with Bazel at all -- they use a remote repository from `src/main/java/com/google/devtools/build/lib/bazel/rules/java/jdk.WORKSPACE` (which don't automatically reflect the version of singlejar Bazel was built with -- it requires snapshots to be taken and uploaded somewhere, then the URLs and hashes updated in that file) that fetches singlejar's source code, and the singlejar used for remote builds is then built on-the-fly. Desugar checking relies on a Protobuf, which is easy to include for the prebuilt version, but Protobuf is not necessarily available when built as a repository somewhere within someone else's build.

So far as I can tell, that's the only issue -- I tried hacking up the `BUILD` files such that the prebuilt version is always used, and it works just fine (when both the client Bazel and the remote execution backend are both running Linux on the same architecture, at least -- I'm not suggesting this as an actual solution, and more to demonstrate that I think the reason this was done was solely because of the Protobuf dependency, not anything more intricate). I'm also guessing the reason it says "in Bazel" in the error message is that this works fine in Blaze, because Blaze always (?) runs inside of google3, and in google3 it is safe to assume you will always have Protobuf available.

[repro.zip]: https://github.com/bazelbuild/bazel/files/3581673/repro.zip