Prefer the runfiles manifest over the runfiles directory (#68)

`runfiles_rlocation_checked` looked up a path in the runfiles directory
before consulting the manifest. Whether the runfiles directory is
populated is a property of how the action or test is executed and is not
known at analysis time, so the directory may exist while holding the
stale contents of a previous execution. Consult the manifest first and
only fall back to the runfiles directory if no manifest exists.

This also fixes `runfiles_current_repository` on Windows with
`--enable_runfiles`. That mode is the only one in which both
`RUNFILES_DIR` and `RUNFILES_MANIFEST_FILE` are set: Windows does not
sandbox, so the runfiles tree used at runtime contains the `MANIFEST`
file that `runfiles_export_envvars` promotes to
`RUNFILES_MANIFEST_FILE`. `rlocation` then returned a path inside the
runfiles tree, but the manifest maps rlocation paths to the locations of
the original files, so the caller could never be the target of a
manifest entry and `runfiles_current_repository` reported every caller
as belonging to the main repository. With the manifest taking
precedence, callers are manifest targets again and the lookup succeeds.

`runfiles_current_repository` had no test coverage at all, which is why
this went unnoticed. Cover all three combinations of the two envvars:
directory only, manifest only, and both set at the same time. The last
case also asserts that a stale copy in the runfiles directory is never
preferred over the manifest.

Future work (https://github.com/bazelbuild/bazel/pull/30674) will allow
the directory to be used again in both functions, assuming it's
materialized.