In 5.6, bWarningsAsErrors does not work with clang

In 5.6, many warnings and errors specify their command line arguments to the compiler with these new C# attributes:

    [WarningsClangToolChain(["-Wno-date-time"], ["-Wdate-time", "-Wno-error=date-time"], ["-Wdate-time"], [nameof(StandardFilters.DeterministcFlagSetFilter)])]  
    [WarningsMSCV(["/wd5048"], null, ["/we5048"], [nameof(StandardFilters.DeterministcFlagSetFilter)])]  
    [WarningLevelDefault(WarningLevel.Off)]  
    public WarningLevel DeterministicWarningLevel  

However, there is a bug that these don't behave the same way in MSVC and clang. Using this one as an example, warningArgs for MSVC is null because this defaults to warning level 1 already, but if you wanted it to be warning level 4, it would be ["/w45048"]. Let's say also that I change the warning level default to WarningLevel.Warning and purposely write code that causes it. When MSVC receives both "/Wx" for warnings as errors and "/w45048", that warning still becomes an error. But when clang receives "-Werror" for warnings as errors and "-Wdate-time -Wno-error=date-time" in an attempt to enable the error and downgrade it to a warning, "-Werror" does not take precedence. It is indeed downgraded to a warning, and the build succeeds.

I was able to fix this locally by changing ApplyWarningsToArgumentsInternal to check (toolChainContext._compileEnvironment.bWarningsAsErrors && level == WarningLevel.Warning), and increasing level to WarningLevel.Error if so. I'm not sure if this is the same solution you would use, as there are probably other ways to handle this.

Steps to Reproduce

1. Change CppCompileWarnings.DeterministicWarningLevel to WarningLevel.Warning, enable bWarningsAsErrors, and write some code that uses _TIME_
2. Compile a game target for Win64 Shipping (or another build if you enable bDeterministic) with MSVC
3. Observe error
4. Compile the same target with clang
5. Observe warning and success