Don't include SDK in runfiles for binaries

[AustinWise]

There are about 3700 files in the SDK, so this can take a while to run on slow file systems.

I measured the impact of this change on Windows by doing the following:

1. Editing examples\basic_csharp\hello.cs
2. Running blaze build //basic_csharp:hello from the examples directory.

Before this change the overall command reported taking about 10 seconds. Afterward it reported taking about 5 seconds.

[AustinWise]

Hmmm, it seems this may be more involved than I anticipated. Closing for now.

[AustinWise]

I looked into the test failures and I'm not sure why they are failing. It is just the "Build and test on RBE :ubuntu: 16.04 LTS (OpenJDK 8, gcc 5.4.0)" job that is failing. I tried to reproduce the failure in the gcr.io/bazel-public/ubuntu1604-java8 Docker image but have not had success.

[purkhusid]

The reason for the failures is that the RBE builds only pull exactly the files that are declared but when running the builds locally the build is not really fully hermetic and the dotnet binary can find all the files that are in the SDK and is effectively escaping the sandbox.

It's gong to be quite a bit of trial and error to get the exact files that are used by the dotnet binary but if you manage to find the minmal list of files then and the RBE also works then that would be a welcome change.

[AustinWise]

Thanks for explaining the difference between local and RBE builds. If I can figure this out, I'll mark this ready for review.