Since commit c1e812ad4f (target_link_libraries: Improve tolerance of
unquoted generator expressions, 2022-02-15, v3.23.0-rc2~11^2) we
accumulate consecutive non-keyword arguments to recover an unquoted
generator expression as a single entry.  When given multiple consecutive
non-genex library names, the grouping breaks our logic that expects each
entry is either a raw target name or a genex.  Revise the logic to only
accumulate multiple arguments when they end inside a partial genex.

This bug caused `target_link_libraries` to stop wrapping static library
private dependencies in `$<LINK_ONLY:...>` for `INTERFACE_LINK_LIBRARIES`
when multiple consecutive library names are given.  Add a test case
covering that behavior.

Fixes: #23302

Prior to commit 1d709ea2f5 (cmGeneratorTarget: Propagate backtraces from
INTERFACE_LINK_LIBRARIES, 2021-12-15, v3.23.0-rc1~228^2), the value of
`INTERFACE_LINK_LIBRARIES` was a single string.  If an unquoted
generator expression passed to `target_link_libraries` contained `;` and
became multiple arguments, they would all accumulate as a single
`;`-separated list in the value of `INTERFACE_LINK_LIBRARIES`.  Since
that commit, each argument to `target_link_libraries` is placed in
`INTERFACE_LINK_LIBRARIES` as a separate entry, as has long been the
case for `LINK_LIBRARIES`. That behavior change broke projects that were
accidentally relying on accumulation in `INTERFACE_LINK_LIBRARIES` to
produce complete generator expressions containing `;`.

Teach `target_link_libraries` to accumulate consecutive non-keyword
arguments into a single entry before placing them in `LINK_LIBRARIES` or
`INTERFACE_LINK_LIBRARIES`.  For example, treat `a b c` as if they were
written as `"a;b;c"`.  This restores the previously accidental support
for unquoted generator expressions in `INTERFACE_LINK_LIBRARIES`, and
also enables it for `LINK_LIBRARIES`.

For now, do not drop the `target_link_libraries` documentation that
recommends quoting generator expressions.  Quoting is still important to
populate `LINK_LIBRARIES` in CMake 3.22 and below, and is also good
practice to keep generator expressions whole.

Fixes: #23203

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.

Run the `clang-format.bash` script to update our C and C++ code to a new
include order `.clang-format`.  Use `clang-format` version 6.0.

Run the `Utilities/Scripts/clang-format.bash` script to update
all our C++ code to a new style defined by `.clang-format`.
Use `clang-format` version 3.8.

* If you reached this commit for a line in `git blame`, re-run the blame
  operation starting at the parent of this commit to see older history
  for the content.

* See the parent commit for instructions to rebase a change across this
  style transition commit.

Fix the CMakeCommands.target_link_libraries test to use "-V" instead of
"-v" on Solaris because the latter does not exist.

Only valid target names or generator expressions may appear in
the target field of a LINK_ONLY expression.

Other content like link flags should still be added to that property
(wrapped in config-specific generator expressions), but not wrapped
in LINK_ONLY. Otherwise undue warnings would be issued for the
policy CMP0022.

The LINK_ONLY expression only has an effect for actual target
names anyway, so there is no logical deficit.

Always populate the INTERFACE_LINK_LIBRARIES for interface
entries. Don't populate the old interface properties
matching (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?
if CMP0022 is NEW.

Because the INTERFACE_LINK_LIBRARIES property is now populated by
the target_link_libraries when operating on a static library,
make an equivalent change which populates the property with
the same value when the old link_libraries() command is used. This
silences the policy warning in that case.