Headers only seen via Bazel virtual includes are unindexable

[garobrik]

Bazel does this thing where headers can be placed in a "virtual includes" folder in the exec root, and then the include dirs passed to the compilation command refer to this virtual includes folder, so that lsif-clang cannot know where the actual source for the header is.

In the case that some entry in the compilation database includes the header via its actual pass in the source tree, this works out fine because we've updated the symbol merging to prefer paths contained by the source tree. But if every entry in the compilation database includes a header via a virtual include, that header will have no LSIF data.

It is also unclear whether this is a bazel specific quirk or if other build systems will also present this problem.

Resolution A: In the project which originally surfaced this issue, the generated compilation database contained entries for individual headers, so all headers got LSIF data. If this behaviour is true of all bazel projects (or we make it true via our bazel tooling) then we're good.

Resolution B: Find a way to map the virtual includes back to their source. There may already be a way to do this with bazel, otherwise we're in very ???? territory. Step 1 seems much more promising and should be attempted first.

Here's some related reading for more context:

bazelbuild/bazel#3828
bazelbuild/bazel#6254

See #28 for more context.

[Strum355]

Also related bazelbuild/bazel#11874

[Strum355]

Interesting commit here, going to see how we could expose this for grail bazel thing to consume