[clang] [clang][clang-cl] Add -fms-preprocessor-compat and support /Zc:preprocessor (PR #167200)

[Josh Dowell via cfe-commits]

Slartibarty wrote:

Sorry about the long delay on this, I have some time now to dedicate to this pull request. I'd like to discuss how we should handle the problem of the charize operator and `/##/` paste trick remaining usable even when `_MSVC_TRADITIONAL` is defined to 0, which is a divergence from MSVC.
I mentioned in a reply that:
> Perhaps the right thing to do here is to not define `_MSVC_TRADITIONAL` at all when using `-fms-extensions`, and relegate it to just `-fms-preprocessor-compat` / `-fno-ms-preprocessor-compat`? I think this would work for most use cases, but I feel that this might go against the expectation of `-fms-extensions` in creating an MSVC-esque environment. These two extensions felt safe enough to leave enabled, but I can see where there would be confusion with a macro that works with Clang, but not MSVC.

There's currently several layers to preprocessor compatibility, and disabling the charize operator and paste trick would add extra complexity where I think the divergence is warranted. Right now `-fms-extensions` enables those two features, and a handful of other small quirks or extensions. There isn't a straightforward way for `-fms-preprocessor-compat-` to disable these tricks, as `/Zc:preprocessor` does in MSVC, because `-fms-extensions` is responsible for those features, so you'd end up with a situation where:

- `-fms-extensions` = can use charize operator and paste trick.
- `-fms-extensions -fms-preprocessor-compat` = ditto.
- `-fms-extensions -fms-preprocessor-compat-` = charize and paste trick are errors.

I don't think either solution is great, trying to match MSVC makes this confusing, and diverging from it isn't great either, I'd appreciate thoughts from others.

https://github.com/llvm/llvm-project/pull/167200