make bazel query try harder to get a list of dependencies

[alsuren]

If I run bazel build "//examples/macos/..." in
https://github.com/bazelbuild/rules_apple then it works fine, but
if I run bazel query "deps(//examples/macos/...)" then it blows up
in my face, complaining about "no such package '@com_google_protobuf//'".

This causes rebazel to have empty list of files to watch.

This patch adds the --keep_going flag to bazel query, so we at
least end up with a partial list of files to watch. In practice, this was
enough to get rebuild-on-save to work for the example files that I
was editing.

I've not used bazel before, so I'm not sure how common this inability
to get deps is. Is this a reasonable hack, or should we instead listen
to the exit code of bazel query and abort, or trigger some kind of
fallback behaviour?

[alsuren]

should we instead listen
to the exit code of bazel query and abort, or trigger some kind of
fallback behaviour?

After reading about a bit harder, I think that maybe a reasonable thing to do would be:

If exit code of bazel query is nonzero and no files were returned, try the query again with bazel cquery (might need to give it the same command-line flags as we're going to give to bazel build to make it do the right thing.

The output of cquery is slightly different from query (superficially, each line has a (tag) at the end, where tag is usually null. After stripping that out, the output of cquery is mostly a subset of query, but with

• a big section called @local_jdk renamed to @remotejdk11_macos
• @bazel_tools//tools/python:pywrapper_template.txt added
• @remotejdk11_macos//:conf/security/openjsse.security added

(to work this out, I did: diff -u <(bazel query --keep_going "kind('source file', deps(//examples/macos/...))" | sort) <(bazel cquery "kind('source file', deps(//examples/macos/...))" | sed 's/ (.*//' | sed 's/remotejdk11_macos/local_jdk/' | sort) | grep ^[+])