Give the third-party crates a platform to be Android on

reindeer resolves features once per platform, and its list here was four
desktop hosts. Adding the device is most of this; `execution-platform =
false` is what keeps it a target and only a target, so a build script still
compiles and runs on the host rather than unifying its own features into the
device's graph.

Two things then had to be true that were not.

The prelude drops every platform-gated dependency for a configuration it
cannot name. DEFAULT_REINDEER_PLATFORMS has rows for Linux, macOS, Windows
and wasm, and none for Android, so the configuration resolved to None,
`platform.get(None, {})` found nothing, and the deps vanished — silently,
surfacing much later as glutin failing on an import it should have had.
set_reindeer_platforms in a PACKAGE file is the prelude's own hook for this.

And khronos_api's build script writes absolute paths. It emits a slice of
include_bytes! calls naming files under the directory it ran in, which buck2
models as an output of the build-script action and exposes no subtarget for:
nothing downstream can depend on it, so the compile that reads the generated
file finds those bytes only when the earlier action happened to leave them on
the same disk. True locally, false on a worker, where it is 36 missing files.
The overlay writes the bytes themselves, so the generated file is
self-contained and where the two actions ran stops mattering. It also sorts
the directory read, which upstream leaves to the filesystem — an order that
differs between the machine that fills a cache and the one that reads it.

jni is renamed because cpal wants 0.21 on the same platform and cpal is a
path dependency, so reindeer gives its deps public aliases too; two crates
called jni cannot both have the name.