[openssl] Fix exported config

[dg0yt]

Describe the pull request

• What does your PR fix?

  Install openssl.pc file ([openssl] Install pc files on all platforms and install openssl.pc #20563).
  Install pc files for Windows ([openssl] Install pc files on all platforms and install openssl.pc #20563).
  Link Windows libraries by name spec without .lib suffix. Some ports (e.g. netcdf-c) put these libraries in pc files, and with --msvc-syntax, .lib added (again).

• Which triplets are supported/not supported? Have you updated the CI baseline?

  unchanged.

• Does your PR follow the maintainer guide?

  yes

• If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?

  yes

[dg0yt]

Concerning risk: some ports may suddenly start to discover openssl via png-config.

[JackBoosY]

Did you test the usage?

[dg0yt]

Did you test the usage?

CMake: No. I think it is safe to assume that it works as well as CMake's recent changes, and that at least one port tested in vcpkg CI uses a canonical find_package(OpenSSL).
Of course we might move on, identify such a port, and remove all the OpenSSL workarounds and patches added by vcpkg.

Pkg-config: No. Every port is using OpenSSL workarounds and patches. Or simply doesn't use openssl. Note that the missing file was discovered with #20556 (libnice) or more precisely for nghttp2 (#20556 (comment)).
Of course we might move on and try to enable openssl in nghttp2. But there is no request for it. Maybe @Neumann-A wants to test with libnice?

But note that this is a by-product of starting to use pkg-config files for nmake/windows in port gdal where invalid exported cmake config made its way into netcdf-c's pkg-config files, breaking the build of gdal. So this going to be part of a solid CI tested network of dependencies around gdal. I'm sure I will touch a lot of ports in that network which use hard-wired transitive dependencies at the moment. That's why I'm reluctant to add additional ports to my list. (I'm just fixing gdal's dependencies for mingw builds again.)

[JackBoosY]

I'd like other guys to double confirm this.

[BillyONeal]

Doesn't MinGW need these too?

[dg0yt]

Mingw already gets pc files, as it is using the unix branch of the port. libcrypto.pc for mingw-dynamic has:

Libs.private: -lws2_32 -lgdi32 -lcrypt32

But my change for windows is based on consuming ports.

[BillyONeal]

Thanks for the help!