Warn about dragons in the Bazel include path

[drigz]

#837 has caused a couple of disappointments for PR authors, so I'm hoping this comment can save them some time, or even help them towards finding a complete solution for the problem.

[drigz]

@cpsauer Let me know if you think this wording would have been helpful for you / if it could be improved.

[cpsauer]

Hey, Diego! Love that you followed up on it.

It'd have flagged to me that something was up--but probably wouldn't have deduplicated spelunking into the what about the implementation of strip_include_prefix provided that (undocumented) Bazel behavior.

You sure it wouldn't make sense to just quickly slay the dragon and be done with it?
[Maybe the easiest would be to just add an include directory around the glog one, pointing includes at that? Or to do so and then move that to the top level if we wanted to be a bit more standard?]
[You're obviously way more experienced with it than me, but it seems like it's been causing some issues and relies on undocumented bazel behavior that could break things under you someday.]

If not, quick suggest on the comment: How about "[leak private headers like stacktrace.h], because strip_include_prefix's implementation only creates symlinks for the public hdrs[.]"

Thanks for all you guys do!
Chris

[drigz]

You sure it wouldn't make sense to just quickly slay the dragon and be done with it?

I wish this were higher up my list of "most expensive technical debt due to my lack of foresight" :( Thanks for the suggestion on the comment.