Make sure libnutclient, libnutclientstub, libnutscan DLLs are installed (WIN32 builds)

[jimklimov]

After solving #1598 we do install headers, .pc pkg-config helpers and static .a and .la files for the libraries above, however shared DLLs (and their .dll.a companions) are neither built nor installed. Static builds of third-party code against the .a files should be possible, and seems they happen for NUT's own codebase on the platform (both linux+mingw cross-builds and semi-native Windows+MSYS2 builds).

This does not directly impact NUT, but can complicate third-party use of its parts via shared libraries (same as is doable on POSIX systems), and does not even waste space since there are approx 1 consumer(s) for each of these libraries in the codebase (maybe automake detects that?):

• the nut-scanner.exe does not reference a libnutscan*.dll so probably has it linked statically as well.
• the tests/cppnit makes use of C++ code in libnutclient during make check-NIT (see Fix C++ nutclient library for WIN32 #1594).
• the libupsclient-6.dll (C client; ABI version 6) does install however, and is used by tools in sbin and cgi-bin.

Recipes do not look too different on first glance, so this task is about figuring out what differs between these, ensuring a "shared" mode build for one but not the others.

Possibly related: there is also a ./lib/libupsclient-config.in file for the legacy helper script (equivalent of pkg-config in modern builds). Maybe gotta spin the thread from here?..

[jimklimov]

Possible hint:

libtool: warning: undefined symbols not allowed in x86_64-w64-mingw32 shared libraries; building static only

...appears a few times during a build. Actually, 2 together and later 1 more. Maybe it is about the 3 libs in question?..

[jimklimov]

Seems the answer was already there for some other recipes: -no-undefined (and then some bugfixing for static libnetsnmp flags detection).