Determine path forward to remove or further embrace xcconfig

[jerrymarino]

The original usage and unfortunate linage of xcconfig for diagnostics is documented on github:
https://github.com/pinterest/xchammer/blob/master/Docs/FastAndReproducibleBuildsWithXCHammer.md#diagnostics

We're stuck with this because there isn't a great way to turn off default flags in Xcode without xcconfig.

Therefore, we use xcconfig to sync up Xcode with Bazel. When we migrated to Bazel we generated .bzl files to represent xcconfig. Today, we manually sync up xcconfig and .bzl when the diags change.

The program mentioned in the doc is included with xchammer now and devs have used this in the past when they refactored diagnostic settings. These diagnostic settings don't often have a reason to change

tools/XCConfigExporter:xcconfig-exporter

Ideally, we can have a solution to disable defaults and sidestep this problem without significant runtime patches. Otherwise, I image an xcconfig evaluator could be integrated as a repository rule or toolchain.