Point _virtual_includes to stable locations so IDE integrations survi…

…ve builds

Hi wonderful Bazelers,

This minor change makes it possible for IDE integrations to play nicely with _virtual_includes. 

Prior to this change, _virtual_include symlinks, themselves in stable, accumulating locations in bazel-out, were pointing into unstable locations in execroot and execroot/external, often invalidated by the next build. This leads to spurious, confusing error messages for the user when subsequent builds made headers no longer findable. Sad times. But with this change, the symlinks stay valid, since they point into the workspace and the accumulating caches in <output_base>/external.

Before we tracked  it down, we received large numbers of issue reports about this over at https:/hedronvision/bazel-compile-commands-extractor, a rather popular tool that enables autocomplete for the C language family across editors and platforms. I strongly suspect it solves similar issues in other IDE adapters, whether they've been traced back to this yet or not. FWIW, I'd previously fixed similar issues in the internal symlinks and include paths of the bazelbuild IntelliJ plugin and Tulsi, back in the day. 

Thanks so much,
Chris
(ex-Googler)

src/main/starlark/builtins_bzl/common/cc/cc_compilation_helper.bzl

@@ -120,7 +120,6 @@ def _compute_public_headers(
  output = virtual_header,
  target_file = original_header,
  progress_message = "Symlinking virtual headers for " + label.name,
- use_exec_root_for_source = True,
  )
  module_map_headers.append(virtual_header)
  if config.coverage_enabled: