cmake: lib CURL_STATICLIB fixes (Windows)

[vszakats]

• always define CURL_STATICLIB when building libcurl for Windows.

  This disables __declspec(dllexport) for exported libcurl symbols.
  In normal mode (hide symbols) these exported symbols are specified
  via libcurl.def. When not hiding symbols, all symbols are exported
  by default.

  Regression from 1199308

  Fixes When building a static library project for Visual Studio with CMake, the preprocessor variable CURL_STATICLIB does not get set #11844

• fix to omit libcurl.def when not hiding private symbols.

  Regression from 2ebc74c

• fix ENABLED_DEBUG=ON + shared curl tool Windows builds by also
  omitting libcurl.def in this case, and exporting all symbols
  instead. This ensures that a shared curl tool can access all debug
  functions which are not normally exported from libcurl DLL.

• delete INTERFACE_COMPILE_DEFINITIONS "CURL_STATICLIB" for "objects"
  target.

  Follow-up to 2ebc74c

• delete duplicate BUILDING_LIBCURL definitions.

• fix HIDES_CURL_PRIVATE_SYMBOLS to not overwrite earlier build settings.

  Follow-up to 1199308

Closes #11914

[vszakats]

A new issue came up: memdebug.c functions cannot be accessed in ENABLED_DEBUG=ON + shared curl.exe builds. Because these functions are missing from libcurl.def and after this PR CURL_STATICLIB leaves them unexported.

https://ci.appveyor.com/project/curlorg/curl/build/job/8olkqly0nb6yb2v9 (CMake, VS2008, Release x86, Schannel)
https://ci.appveyor.com/project/curlorg/curl/build/job/x61dq69gdtsq7fvx (CMake, VS2022, Release x64, OpenSSL, WebSockets, Unity)

Plus there is curl_easy_perform_ev() going on a different track than memdebug functions, and ending up missing too.

[vszakats]

Solved the ENABLED_DEBUG=ON + shared tool case by introducing libcurl-debug.def.

This relies on CMake merging the two .def files before passing to the linker. Linkers may not natively support multiple .def files (couldn't yet figure out if this needs a specific CMake version), e.g. lld honors only the last one passed. It means the Makefile.mk use needs further fixing.

UPDATE: Seems to require CMake 3.12.0, so this solution is doubly no good.

[vszakats]

Solved this one by extending libcurl-debug.def to include all standard libcurl API definitions as well. Plus a test for it. This fixes debug + shared tool builds with both older CMake and Makefile.mk builds.

This perhaps isn't the most elegant solution, but I cannot think of a better one. Other alternatives may be to:

• Split off debug functions to a separate lib and link that statically always (this would be likely more complex.)
• Find a CMake feature that is able to set list of exports with a regex (curl_*) for all supported compilers (like autotools does).
• Either:
  • drop Windows support from Makefile.mk.
  • find an lld/ld option to limit exports to a regex (like libtool's "-export-symbols-regex '^curl_.*'") [There don't seem to be such option.]
  • dynamically generate .def via our existing Perl script (making Perl a hard requirement there) [This worked fine locally as an experiment].
• Export all symbols for debug builds.

[vszakats]

Next issues:

1. non-Windows symbol curl_dbg_socketpair is picked up by tests/extern-scan.pl.
2. tests/extern-scan.pl misses to pick up curl_dbg_malloc, curl_dbg_calloc, curl_dbg_realloc.

UPDATE: fixed.

[vszakats]

Tending to prefer the option 'Export all symbols for debug builds' as a reasonable compromise. This makes it unnecessary to roll a libcurl-debug.def.

[vszakats]

Strange error from a single CI job for the test added in this PR:

=== Start of file stderr3203
 Unsuccessful open on filename containing newline at ../../tests/extern-scan.pl line 88.
 readline() on closed filehandle H at ../../tests/extern-scan.pl line 90.
 Unsuccessful open on filename containing newline at ../../tests/extern-scan.pl line 88.
 readline() on closed filehandle H at ../../tests/extern-scan.pl line 90.
=== End of file stderr3203

Ref: https://github.com/curl/curl/actions/runs/6281395226/job/17062947662?pr=11914#step:11:3161