The goal here is to try and create more predictable binary files and remove the possibility that
a full source path (via __FILE__) gets baked into the shared libraries or executables shipped.

So:
 * replace use of __FILE__ to the macro THIS_FILE with just the basename of the source file being compiled

The __FILE__ issue is that it has an implementation defined string literal value, depending on the compiler
and the filename supplied on the compile line. By changing to the new THIS_FILE macro, the object files
will always have a consistent string literal in them, making it easier to compare binaries between builds.
Something we have never been able to do in the past. Granted it's just the basename for the file, but should be enough.
The tricky part is that __FILE__ only gets evaluated when it is used. In normal C code, it will appear in
macros but it only will get evaluated in the source file being compiled. It is rare that macros using
__FILE__ will get expanded in include files and I detected this not happening in the jdk source at all.