Default Win32 desktop transport to WinHTTP instead of WinInet

[bmehta001]

Problem

HttpClient_WinInet (the default Win32 desktop HTTP transport) depends on a
logged-on interactive user and that user's Internet Explorer proxy settings.
Microsoft documents WinInet as not supported for use in Windows services
or other non-interactive processes. Since 1DS's dominant real-world embedding
scenario is exactly that -- a background/service telemetry SDK -- WinInet is
the wrong default transport for most consumers.

Change

Add lib/http/HttpClient_WinHttp.hpp/.cpp, a new IHttpClient transport
using the WinHTTP API, and make it the default Win32 desktop (non-WinRT)
transport. HttpClient_WinInet remains available as an explicit opt-in
(MATSDK_USE_WININET=ON via CMake, or HAVE_MAT_WININET_HTTP_CLIENT for the
legacy MSBuild solution) for callers that specifically need IE-integrated
proxy/cookie behavior.

Design notes (where this isn't just a mechanical port of WinInet)

• Proxy resolution: WinHttpOpen uses WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY
  (Windows 8.1+), which resolves the proxy without needing a logged-on user,
  falling back to WINHTTP_ACCESS_TYPE_NO_PROXY if an older OS rejects it.
• Async model: WinHTTP reports one distinct callback status per stage
  (SENDREQUEST_COMPLETE -> HEADERS_AVAILABLE -> DATA_AVAILABLE/READ_COMPLETE
  loop -> REQUEST_ERROR), unlike WinInet's single INTERNET_STATUS_REQUEST_COMPLETE.
  A FALSE return from an async-handle call is always a genuine synchronous
  failure here (WinHTTP has no ERROR_IO_PENDING convention like WinInet).
• Response cap: the existing MAX_HTTP_RESPONSE_SIZE DoS guard (Cap HTTP response body size across WinInet, WinRt, and Apple transports #1508) is
  enforced the same way, before every read.
• MS-root cert check: rebuilds the chain via CertGetCertificateChain,
  since WinHttpQueryOption only returns the leaf certificate, unlike
  WinInet's ready-made chain context option.
• Request lifetime: uses shared_ptr/enable_shared_from_this rather
  than WinInet's raw-pointer self-ownership. WinHttpCloseHandle on a
  request with a pending operation blocks the calling thread until that
  operation's completion callback -- which runs on a different WinHTTP
  worker thread -- finishes. Holding the shared requests-map mutex across
  that call (WinInet's pattern, safe there because its callback runs
  synchronously on the calling thread) deadlocks here, since the callback
  thread needs that same mutex to erase() the completed request.
  shared_ptr lets cancellation release the map lock before the blocking
  close while still safely keeping the wrapper alive against a concurrent
  natural completion.
• Cancellation drain: CancelAllRequests() waits on a condition variable
  signaled from erase() instead of polling in a sleep loop.

Both .cpp files are always compiled; the transport choice is made at
HttpClientFactory's #include/#ifdef site, matching the existing
WinRt-vs-WinInet pattern. Wired into both build systems: lib/CMakeLists.txt
(new sources, winhttp link library, MATSDK_USE_WININET option) and
lib/pal/desktop/desktop.vcxitems (new sources; linking uses
#pragma comment(lib, "winhttp.lib") in the new .cpp, so no individual
.vcxproj's AdditionalDependencies needs updating).

Validation

Windows x64 Debug, both CMake and the Solutions\MSTelemetrySDK.sln MSBuild
path actually used by CI (build-tests.cmd / test-win-latest.yml):

• UnitTests: 496/496 passed.
• FuncTests: 43/43 passed, excluding sendManyRequestsAndCancel, which
  hits the real production collector over the internet. That specific test
  hangs identically with the original, unmodified HttpClient_WinInet
  under the same back-to-back test sequence -- confirmed by direct
  comparison -- so it is pre-existing network/infrastructure flakiness
  unrelated to this change, not a regression.
• Found and fixed two real bugs during validation:
  1. WinHttpSetStatusCallback's return value was checked as a boolean, when
     it actually returns the previous callback function pointer (typically
     null on first registration) -- this rejected every request immediately
     after registering the callback. Confirmed by a targeted functional test
     going from failing (0 requests ever reaching a local test server) to
     passing.
  2. The WinHttpCloseHandle cross-thread deadlock described above,
     reproduced live via a hung sendManyRequestsAndCancel run (static CPU,
     blocked threads) and confirmed fixed by the same test completing in
     ~18s after the shared_ptr change.