Draft: Add dependency registry to keep track of exported library dependencies

Follow up MR from !1249 (comment 127761)

Issue

Resolution of library dependencies currently relies on loading all of the dune macros. This is very unpractical and what consumes most of our build time. This MR aims to keep track of the dependencies introduced by a module internally, and check if such package is being exported. If so, the required macro is resolved at config time when loading find_package(<module>). This is a companion MR of !1249 (merged) to handle package dependencies at find_packate(<module>) time.

Proposal

The idea is to track what is exported via HAVE_FOO or ENABLE_FOO=1 exposed in the target cmake files. If those entries are present, the downstream module also needs to see module Foo, otherwise, it was an internal requirement of the upstream module. Naturally, this feature relies on the fact that exported targets expose their dependencies requirements in its compile definition options (i.e. INTERFACE_COMPILE_OPTIONS property) via HAVE_FOO or ENABLE_FOO=1. If such a requirement appears in the exported target, the macro that provided such requirements (e.g. AddFooFlags) is also loaded in the downstream module at find_package(<module>) time. Since this is transitive handling of dependencies, libraries may consume dune macros internally, but they will only be exposed to downstream projects if the requirements are exposed in the exported targets.