Generated includes file incorrectly prioritizes user headers over system version

The TensorFlow Lite source tree contains a header file with the name "string.h", inside the folder tensorflow/lite/. When compiling an mbed project with this nested file, any code that does `#include ` will import this version instead of the expected system header, causing mysterious compiler errors early in the process.

Other users have encountered the same problem: https://os.mbed.com/questions/85362/include-path-uses-incorrect-search

I thought I'd found a workaround by using .mbedignore to exclude the tensorflow folder and subdirectories, but while that gets around the earlier compilation errors, it has the unfortunate side effect of also not compiling the code in those folders.

After some digging, I found that the include paths were being set by a file like `@./BUILD/DISCO_F746NG/GCC_ARM/.includes_18349b8ce7da3e19df69aba86e441bb6.txt`. This contains a long list of `-I` directives, apparently for every subfolder in the workspace. There are a few problems with this:

- Using `-I` means that every file is treated as a candidate for angle-bracket (system) includes. This is not what developers would normally expect for their own headers.
- Recursively searching every subfolder is pretty surprising behavior too.
- All of these directives override the default system headers, since they're searched first.

I would love any suggestions on workarounds. Renaming the current offending string.h in our codebase might work in the short term, but it's likely that other headers will hit similar issues in the future.