Regression: 3.24.0 enforces IMPORTED_LINK_DEPENDENT_LIBRARIES on import

Original title: Private shared library dependencies of exported library now checked at import

CMake 3.24 introduced a change that makes libraries in IMPORTED_LINK_DEPENDENT_LIBRARIES turn up in the missing files list, which breaks libraries which do not explicitly import these libraries before including the target script.

The specific change seems to be this, as the entries ended up in a dummy vector before: !7165 (diffs)

This lead to issues in OBS Studio because of the following situation:

• libobs requires w32-pthreads
• Both are built as shared libraries, obs.dll links to w32-pthreads.dll
• Both are exported as packages
• w32-pthreads ends up in IMPORTED_LINK_DEPENDENT_LIBRARIES for libobs.
• OBS plugins are loaded at runtime (not linked) and themselves only link to obs.dll
• OBS plugins find libobs via its exported package name

We had errors in our libobsConfig.cmake (one was running find_package instead of find_dependency) that lead to dependencies being found after importing the target script:

• In CMake 3.23 this didn't lead to any issues, as IMPORTED_LINK_DEPENDENT_LIBRARIES didn't have any effect.
• In CMake 3.24, the value(s) are now added to the target script (# Make sure the targets which have been exported...), but because we don't run find_dependency before, a FATAL_ERROR is emitted.

The documentation for IMPORTED_LINK_DEPENDENT_LIBRARIES states that it contains values for platforms where linked shared library dependencies are needed at link time (read: Linking to obs.dll requires the linker to be able to resolve w32-pthreads.lib as well, even though the current library does not use any symbols from it). Thus the "new" behaviour seems more correct at first glance, but also leads to sudden breakage on GitHub Actions as GitHub has been rolling out CMake 3.24 on its Windows systems.