[feature] Delay loading of optional DLLs with CMake

[mlt]

This continues discussion started in #28394.

I'd like to propose a solution for packagers to utilize delay loading mechanism for optional DLLs. This generally reduces startup time and allows to decouple optional features into optdepends in a true spirit of Arch & pacman to keep only bare minimum that works in depends.

This involves a new package ${MINGW_PACKAGE_PREFIX}-delay-load-support constisting of CMake helper module and small C code. The purpose of C code is to notify an end user when an attempt was made by the main app to load optional DLL but is was not available. In such case the user would be greeted with a standard message like the one below and the process will terminate hard.

To use this package, one needs to add a patch that would add just 2 lines into CMakeLists.txt after target and and link libraries are defined similar to these

include(DelayLoad)
target_delay_load(mongoc_shared "snappy|libz|zstd|utf8")

The first line loads CMake module and the second calls the function that would go over all dependent libraries of a TARGET recursively and will make necessary adjustments if import library name matches a REGEX. It also embeds into TARGET pre-compiled object file with the aforementioned C code.

P.S. It looks like with current CI setup I can't introduce a new package and depend on it in the same PR. I'll leave it for now to get an idea, but will split into 2 if approved.

[oscarfv]

If my understanding is correct, this change would require patching the CMakeListst of the affected packages (which implies that packages that don't use CMake are excluded.) Looks like a serious maintenance burden. Then, there is the potential for problems with those packages that already play tricks with delayed dlls. Finally, the message it shows doesn't look all that clear about what really happened and what the user should do to fix the problem.

The intention is good, but the execution looks way too problematic.

[mlt]

packages that don't use CMake are excluded… maintenance burden

That is correct. I meant it as an opt-in feature and gradual adoption. I have no intention to mandate the usage of it everywhere. With only 2 lines for changes, it is easy to opt-out later if necessary.

The benefits might be questionable if it is only one extra DLL that is used in half of the cases and there are no other patches for a package. On the other hand, there are packages like hdf5 that pull 9 aws-c dependency packages that may not be needed for local usage.

problems with those packages that already play tricks with delayed dlls

If something is already using alternative techniques or you feel particular about your beloved package, there is no crime in leaving it as is.

message it shows doesn't look all that clear

If you look into C code, the message itself is not there. This is a standard localized message that appears if you remove one of DLLs used by some app. I piggy backed on it with (optional) prefix before dll name.

I had thoughts about the clarity as well. I have alternative piece that shows more meaningful message box if it is a GUI session, dumps a note into stdout if it is connected, and leaves a mark in Event Log. We can do that instead and discuss how as well as i18n implications. As it is, it is the minimal piece I came up with.

On a tangential note, the error messages for optional packaged python libraries is not any better. I'm poking around pymongo, as is, if pymongrocrypt is missing, it says

pymongo.errors.ConfigurationError: client-side field level encryption requires the pymongocrypt library: install a compatible version with: python -m pip install --upgrade 'pymongo[encryption]'

It does not say that I should pacman -S mingw-w64-ucrt-x86_64-python-pymongocrypt. So if we say which DLL is missing, it is more than enough in my opinion.