windows: tidy up wincrypt.h / BoringSSL/AWS-LC coexist workaround

[vszakats]

• openssl: move and expand explanatory comment.

• openssl: drop duplicate workaround.

• schannel: drop workaround. Unnecessary, because OpenSSL headers are
  not included in or after schannel code.

• schannel: drop explicit wincrypt.h include. It's indirectly
  included by system <schannel.h>.

• ldap: drop explicit wincrypt.h include.
  It isn't used there, and also not required for the workaround.
  winldap.h keeps including it indirectly.

Tested with BoringSSL and AWS-LC (MultiSSL with Schannel), also LDAP
enabled, and H3, unity and non-unity, and all tested cases build fine.

In lib in general, the point is to have the #undefs between the first
wincrypt.h include [1] and the first OpenSSL include [2], within a
single compilation unit. For non-unity builds the only such source is
openssl.c. For unity ones, depending on batch size, in theory the
#undef should be used after each wincrypt.h include. In practice
this is overkill and most cases are covered by #undef-fing first in
vtls/openssl.c, and #undef in ldap.c. It's not impossible that
more undefs need to be added after more wincrypt.h includes to cover
so far undiscovered build cases [3]. Though I could not find more with
the current sources and source order.

It's also an option to include OpenSSL first, then wincrypt.h, as
done in libtests, but for lib and vtls/openssl.c it's more practical
to do the opposite.

[1] can be indirect, e.g. via iphlpapi.h, schannel.h, winldap.h.

[2] in

• BoringSSL/AWS-LC: any include (due to openssl/base.h).
  Original fix removed by BoringSSL in year
  2014.
• OpenSSL: openssl/ssl.h, openssl/x509v3.h, and some more affected,
  and including openssl/ossl_typ.h does the #undef automatically.
  Since 3.1.0+
  #undef is done on each inclusion, in 3.0.x (and earlier) only on
  the first inclusion. Initially fixed in
  0.9.6d
• LibreSSL 2.3.0+:
  not affected, though to suppress another warning 3.8.2+ and
  a define
  is necessary.

[3] The order of unity sources are defined by lib/Makefile.inc.

For libtests, the case is simpler: There is always one compilation unit,
with a fixed order, and at the moment cli_hx_download.c is including
OpenSSL first, then wincrypt, and in this order they don't bother each
other. Also, at the moment lib758.c is the only other OpenSSL header
user, but it's compiled after cli_hx_download.c so the include is
skipped there. This needs to be revisited if either header gets included
before it.

All this said it'd be nice if BoringSSL/AWS-LC restored the built-in
workaround to behave like LibreSSL and OpenSSL and not require local
workarounds like these.

Ref: #20556 (comment)

Follow-up to 4c46c82 #9110
Follow-up to fbe07c6 #5669 #5857