Tell the dependent crates where the ggml CMake package is

[bogdanr]

The CMake build already installs a ggml package config, but no crate can find
it, because the build script does not print the path. This change prints it:

cargo:ggml_cmake_dir=<OUT_DIR>/lib64/cmake

Cargo gives the value to dependent crates in DEP_LLAMA_GGML_CMAKE_DIR. This
is the same method as the backends_dir value above it. The build script looks
in lib64/cmake/ggml and then lib/cmake/ggml, and prints nothing if it finds
neither.

Why

A program that uses llama-cpp-2 and whisper-rs together contains two copies
of ggml, and they are not the same: GGML_TYPE_COUNT is 42 in recent llama.cpp
and 40 in whisper-rs-sys 0.15.0. Users must give the linker
--allow-multiple-definition or /FORCE:MULTIPLE. The linker then discards one
copy, and half of the program uses a 42-entry table through code that expects
40 entries. We saw this stop a program with STATUS_HEAP_CORRUPTION.

whisper-rs has an open PR for WHISPER_USE_SYSTEM_GGML
(#260), but it needs the
path of an installed ggml. This change supplies that path.

Test

We made a program that starts a LlamaBackend and whisper, and built it two
times on Linux with rust-lld and no linker flag.

Without whisper-rs/system-ggml:

rust-lld: error: duplicate symbol: ggml_backend_buft_name
... (lld stops after 20 errors)

With whisper-rs/system-ggml and CMAKE_PREFIX_PATH set to the new path, it
links and runs. whisper-rs-sys builds 0 ggml archives instead of 6, and
nm --defined-only <bin> | grep -cw ggml_init gives 1.

Limits and risk

Cargo gives DEP_LLAMA_GGML_CMAKE_DIR only to direct dependents.
whisper-rs-sys is not one today, so users must set CMAKE_PREFIX_PATH, as in
the test. A subsequent change to whisper-rs-sys can add an optional dependency
on this crate and read the variable.

Risk is low: no new feature, no new dependency, no change to a build step.
cargo fmt and cargo clippy are clean.