* Don't recreate GOST EC groups every time

For multiple keygen it saves 6% time

...in DN output

MacOS ld doesn't support -rpath, so we must be able to not use it there.

Now that .github/before_script.sh works properly on MacOS, there is
no reason not to use it for this job as well.

It makes sure to install it where site perl scripts should be located.

Fix #346

Cmake 3.0 was a switch to using targets and properties rather than
variables when linking different components together.
We follow that philosophy by dropping ${OPENSSL_CRYPTO_LIBRARIES} and
${OPENSSL_SSL_LIBRARIES} in favor of OpenSSL::Crypto and OpenSSL::SSL.

Cmake is generally good at tracking specified dependencies between
libraries.  All that we need to do is to establish a dependency on
OpenSSL's libcrypto for 'gost_core', and then we can reduce the amount
of repeated dependencies for everything that links against 'gost_core'.

The static OpenSSL libraries have some dependencies that need to be
recorded fofr everything that's linked against it.  To achieve this,
we use ${OPENSSL_CRYPTO_LIBRARIES} and ${OPENSSL_SSL_LIBRARIES}
instead of ${OPENSSL_CRYPTO_LIBRARY} and ${OPENSSL_SSL_LIBRARY}.

OpenSSL commit https://github.com/openssl/openssl/commit/74b7f339aa58af57c0e71b7efca66e6f2db5ae2e
changed the default installation path on 64-bit systems.

The recommended workaround is appending --libdir=lib

More earlier versions don't properly detect OpenSSL 3.0.
BTW, workarounds still exist

Merge branch 'update-codeql-analysis' of https://github.com/levitte/engine into levitte-update-codeql-analysis

These days, the OpenSSL cmake package finder is capable of finding
a custom OpenSSL installation with no OPENSSL_ROOT_DIR defined, but
CMAKE_PREFIX_PATH defined.

However, gost-engine's CMakeLists.txt does use OPENSSL_ROOT_DIR, so
it needs it to be defined unconditionally.  That's arranged fairly
easily by assigning it the parent directory of OPENSSL_INCLUDE_DIR.

Most of all, at least openssl-3.0.0-alpha16 is needed, because there
are API changes made in that release that affects gost-engine builds

The C flags were set to be highly optimized regardless of the cmake
build type.  This may make debugging difficult.  To resolve that, we
adapt the C flags to the cmake build type in a supported manner.

(cherry picked from commit 1b684f3f)

This test is so internal that it doesn't even need the engine.

The following programs had a hard coded load of the gost engine.
This changes them to rely more on the testing environment, and to
load engines through configuration files.

This affects: test_ciphers.c, test_context.c, test_derive.c,
test_digest.c, test_params.c, test_sign.c, test_tls.c

It's not right to have segmentation faults.

When building in a directory that's separate from the source
directory, test results should end up in the build directory, not the
source directory.

Essentially, unless you do build in the source directory, it should be
regarded as read-only when building.

Cmake doesn't support the variable CMAKE_INSTALL_DIR.  However, with
the GNUInstallDirs module, there is the variable CMAKE_INSTALL_MANDIR.

From 3.0.0-alpha6 to 3.0.0-alpha13, mostly for Analysis to avoid
getting failures when compiling, considering that the GOST source has
adapted for the latter version.

Using cNORM after "\n" may or may not work, probably because of the
line buffered nature of standard output.

If an error is displayed immediately after a printf that has cNORM
after "\n", the error output sometimes "overrides" the cNORM, and you
may end up with a surprisingly colorful error message, not to mention
that this may also affect your prompt in the same manner.

The lesson is to always output cNORM before the ending "\n".