Fixes: #22929

Due to MCST LCC compiler identification is now changed to LCC,
there should be a way for old projects to still identify it as GNU,
as it was before.
This commits adds the policy:
CMP0129: Compiler id for MCST LCC compilers is now LCC, not GNU.
This policy controls such a behavior.
OLD behaivior is to treat LCC as GNU, NEW is to treat is as LCC.

Divert LCC compiler as a new one, instead of treating it as GNU.

Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been
passing checks for GNU compilers, so it has been identified as GNU.
Now, with intent of seriously upstreaming its support, it has been
added as a separate LCC compiler, and its version displays not a
supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead
of GNU 7.3.0).

This commit adds its support for detection, and also converts basically
every check like 'is this compiler GNU?' to 'is this compiler GNU or
LCC?'. The only places where this check is untouched, is where it
regards other platforms where LCC is unavailable (primarily non-Linux),
and where it REALLY differs from GNU compiler.

Note: this transition may break software that are already ported to
Elbrus, but hardly relies that LCC will be detected as GNU; still such
software is not known.

Treat it just like PGI.

Since commit d44c0db0b2 (clang: setup correct configuration in gnu mode,
2019-02-20, v3.15.0-rc1~41^2~5) we support the GNU-like Clang that
targets the MSVC ABI.  However, Clang cannot compile with the MSVC
standard library unless it runs in a mode aware of C++14 (since MSVC
itself does not even have a lower mode).  When `CMAKE_CXX_STANDARD` is
set to 98 or 11, use C++14 anyway.

Since Clang's default mode is aware of C++14, another option is to not
add any flags for 98 or 11.  However, if a future Clang version ever
defaults to a higher C++ standard, setting the standard to 98 or 11
should at least not use a mode higher than 14.

Also revert test updates from commit 4819ff9647 (Tests: fix failures
with gnu mode clang on windows, 2019-03-21, v3.15.0-rc1~41^2~3) that
were meant to work around the standard selection problem.

Fixes: #19496

    Root causes were:
    * Using incorrect conditions (assuming MSVC-like command line mode)
    * Trying to compile the MSVC STL in C++11 mode, when parts of it require
      C++14 or enabling MS extensions in clang.
    * Missing flush in a testcase using stdout in a dll and a main part
    with static crt

Previously compilers that only supported the meta-level flags
would not have any of the granular features listed. Now we
presume that they have full support and enable all the features.

Update granular feature tests to skip the actual compilation
checks for the presumed features.