Better handling of cmake cache paths

[ysimonson]

Use a proper API/crate for extracting library paths from cmake rather than reading the cache file which is unstable. This came up in the discussion in https://codeberg.org/tazz4843/whisper-rs/pulls/260.

[MarcusDunn]

I'm not familar enough with cmake or linking to judge if this is a good idea - it certianly moves complexity into this crate. could you explain what's this changes and what the issue was?

If it's a caching issue, when does it occur? why doesn't cmake figure out the cache is invalid and reconfigure? do we lose out on caching every build if this feature is enabled?

[ysimonson]

The code on main reads the cmake cache file to figure out where the system GGML libraries are. This works, but there's no guarantees on the stability of the format. A future cmake could break this build process, though I'm not sure in practice how realistic this possibility is. This PR uses a crate that relies on the stable cmake file API. It offers better stability against potential future cmake changes, at the cost of pulling in a build dependency.