- rustc_env now expands $(rootpath //package:target), for passing
the location of files or tools that are needed at compile time
- build_script_env now expands $(execpath //package:target), for
passing the location of files or tools that are needed at build
script runtime
- cargo_script_build() now passes the data argument to the build
script runner, so the data is available at runtime

Ideally both build and run would work with execpath/location, but
the approach of walking back to the root folder that cargo_build_script()
is using doesn't seem to be possible at compile time, as ${pwd} is being
substituted after the starlark code is executed. So at compile time,
we use the relative rootpath instead.

Rust on Windows seems to struggle with relative pathnames in this case
- I suspect due to the fact that symlinks are being used.

fs::read_to_string("../../../path/to/somewhere")

gives an error

as does calling .canonicalize() on the above. Switching to \ as a
path separator does not seem to help.

If the parent directory references are handled separately, eg

Path::new("../../..").canonicalize(), then the path/to/somewhere
can be joined onto the folder and the file can be read. So instead
of automatically adjusting the path, we just return execroot verbatim,
and rely on the build script to do their own path manipulation.

Re discussion on
bazelbuild#461 (review)