fix: Avoid false success for -fcolor-diagnostics probe with GCC

fix: Avoid false success for -fcolor-diagnostics probe with GCC

Ccache will produce a false hit in the following scenario, if "cc" is
GCC without being a symlink to "gcc":

  1. ccache cc -c example.c                      # adds a cache entry
  2. ccache cc -c example.c -fcolor-diagnostics  # unexpectedly succeeds

(Most major Linux distributions install cc as a symlink to gcc, and then
the problem doesn't show up since ccache then is able to guess that the
compiler is GCC.)

This bug was introduced by [1] which tried to make yet another tweak of
the color diagnostics guessing/probing by no longer rejecting
-fcolor-diagnostics for an unknown compiler, based on the assumption
that the probing call (speculatively adding -fdiagnostics-color) is only
made when we have guessed a GCC compiler. Unfortunately, this broke the
fix in [2] when the compiler is unknown.

All of this is inherently brittle and I don't see any good way to make
it better with the current compiler guessing approach and adding options
speculatively. The cure is to start doing proper compiler identification
instead (#958). Until that is done, the only reasonable fix is to avoid
doing anything related to color diagnostics flags when the compiler is
unknown. This means that an unknown compiler from now on won't produce
colors when used via ccache even if the compiler actually is GCC or
Clang.

[1]: 97a40af49f56e4be2db5e4318d8131e937bd5598
[2]: 61ce8c44c5b1da0be7a8d10c014f1a85b7967433

Closes #1116.