Windows: Add option to build CMake's internal curl with winsspi

[johnwparent]

CMake's internal copy of curl used with the +ownlibs variant has the ability to link against the winsspi.dll, a Windows native implementation of SSL. This PR exposes another variant of the CMake package on Windows allowing users to build CMake with winsspi, rather than OpenSSL.

Some small, Windows specific cleanup was also done in this PR.

[chuckatkins]

Just recently in #29847 the openssl variant was dropped as it's not particularly useful to have a CMake that uses curl without ssl support. Rather than add another variant I think it just makes more sense to always use the native windows ssl.

@BetsyMcPhail ?

[scheibelp]

Just recently in #29847 the openssl variant was dropped as it's not particularly useful to have a CMake that uses curl without ssl support. Rather than add another variant I think it just makes more sense to always use the native windows ssl.

This preserves that choice but is allowing Spack to set the SSL implementation (and also updates the CMake package to choose the Windows-provided SSL by default). I think it's a separate discussion whether that choice should be retracted entirely (for now these changes are needed to generally build, and removing the variant is a matter of deciding whether the user should be allowed to undo that choice) so I'm inclined to merge this as is.

[haampie]

what's the deal with all this is_windows? you should always check the target, not the host, we have platform=... for specs. All this is_windows stuff is so unreadable, please improve it. Also the nesting with - if - with - f() does not help in improving readability...

[johnwparent]

Just recently in #29847 the openssl variant was dropped as it's not particularly useful to have a CMake that uses curl without ssl support. Rather than add another variant I think it just makes more sense to always use the native windows ssl.

This preserves that choice but is allowing Spack to set the SSL implementation (and also updates the CMake package to choose the Windows-provided SSL by default). I think it's a separate discussion whether that choice should be retracted entirely (for now these changes are needed to generally build, and removing the variant is a matter of deciding whether the user should be allowed to undo that choice) so I'm inclined to merge this as is.

FWIW I spoke with Brad King and Bill today, and in general it seems the consensus is that with this support for the use of winsspi.dll, we should no longer even offer the option to build with OpenSSL. I can provide more detail/context if needed, but if we want to make another PR to that effect, such detail can be reserved until that point.