* upstream-LibArchive:
  LibArchive 2022-12-09 (ba80276c)

Compile some third-party libraries with preprocessor definitions that
activate POSIX APIs even when compiler extensions are not enabled.
We already do this in libuv, inherited from the upstream buildsystem.

This extends commit f034b0f663 (CMake compilation: do not use compiler
extensions, 2020-03-14, v3.18.0-rc1~494^2).

Issue: #20454

be9ebc104a libarchive: Simplify code selecting CMake-specific build options
4a7a5718c6 libarchive: Update build within CMake after changes in 3.6.0
85cdeefc37 libarchive: include archive_platform.h first in blake2s sources
b3644e460f Merge branch 'upstream-LibArchive' into update-libarchive
5d50940288 LibArchive 2022-02-09 (9147def1)
406503f620 libarchive: Update script to get 3.6.0

Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !6988

libarchive's crypto library checks use its `config.h` inside the
`try_compile` project.  Since commit ade3b16e63 (libarchive: Use KWIML
to get fixed-size integer types, 2020-06-01, v3.18.0-rc1~33^2),
that header depends on KWIML inside CMake.  Add the include directory
for KWIML to the crypto library checks.  Otherwise, they always fail
due to not finding the KWIML headers, and libarchive decides not
to link the crypto library.

libarchive has other code besides the hash algorithms that depends on
the crypto library if its ENABLE_OPENSSL option is enabled (which in
CMake is controlled by CMAKE_USE_OPENSSL).  It seems to be missing some
conditions to link the crypto library in those cases, and instead relies
on at least one of the above-mentioned checks to pass.  If they all
fail, and we are using system curl, we might not link the crypto
library.

Fixes: #23234

Reduce differences from upstream libarchive `CMakeLists.txt` code.
Remove modifications inside code we disable anyway.

* upstream-LibArchive:
  LibArchive 2022-02-09 (9147def1)