Add Bazel unit test target and Windows (MSVC) support

[BYVoid]

Summary

Follow-up to #501, in two parts:

1. Unit tests under Bazel — a cc_test target covering the server-independent subset of the existing googletest suite in ut/, wired into the Bazel CI workflow.
2. Windows (MSVC) support — the Bazel build now links on Windows for all three TLS modes, and windows-latest is added to the CI matrix. MSVC is the toolchain here because it is what Bazel supports on Windows — Bazel has no MinGW support (unlike the CMake build, which has a separate MinGW CI workflow), so the existing Windows mingw coverage remains CMake-only.

Part 1: Unit tests

File	Change
ut/BUILD.bazel	New //ut:unit_tests cc_test target
MODULE.bazel	googletest 1.17.0.bcr.2 from BCR, marked dev_dependency = True so library consumers never pull it in
.github/workflows/bazel.yml	New bazel test //ut:unit_tests step on the matrix

Test selection — only tests that run hermetically, i.e. no running ClickHouse server required:

• Included: types_ut, type_parser_ut, columns_ut, column_array_ut, block_ut, itemview_ut, stream_ut, utils_ut, CreateColumnByType_ut, plus socket_ut (spins up its own LocalTcpServer on localhost, which works inside the Bazel test sandbox), together with the shared support code (utils.cpp, value_generators.cpp, tcp_server.cpp) and the gtest main.cpp.
• Excluded (CMake-only for now): everything that connects to $CLICKHOUSE_HOST — client_ut, roundtrip_tests, Column_ut, low_cardinality_nullable_tests, array_of_low_cardinality_tests, abnormal_column_names_test, readonly_client_test, connection_failed_client_test, performance_tests, ssl_ut. These keep running in the CMake CI, which provides a server via docker-compose. Running them under Bazel (e.g. with a dockerized server fixture) could be a future follow-up.

The split is documented in a comment at the top of ut/BUILD.bazel. googletest is a dev_dependency, so it does not participate in version resolution for downstream consumers — it only exists when this module is the root.

Part 2: Windows support

Adding windows-latest to the matrix surfaced that the Bazel build didn't link on Windows except by luck:

• tls=no and tls=openssl failed with LNK2019: unresolved external symbol __imp_ntohl / __imp_socket / ... — the Winsock library was never declared.
• tls=boringssl only worked because BoringSSL's own BUILD file propagates ws2_32 to its dependents.

Fixes, mirroring what the CMake build already does:

File	Change	CMake counterpart
BUILD.bazel	linkopts: -DEFAULTLIB:ws2_32.lib on Windows	IF (WIN32 OR MINGW) TARGET_LINK_LIBRARIES(... wsock32 ws2_32)
ut/BUILD.bazel	/bigobj on Windows	IF (MSVC) TARGET_COMPILE_OPTIONS(... /bigobj)
MODULE.bazel	platforms 1.1.0 (for @platforms//os:windows in select())	—

Notably, the BCR openssl module itself compiled cleanly under MSVC — the failure was purely the missing Winsock declaration in this repo's BUILD file.

CI

The Bazel workflow matrix is now 3 OS × 3 TLS modes = 9 combinations (Linux, macOS, Windows × boringssl, openssl, no), each running build + unit tests. All 9 are green on this branch.

Test plan

• bazel test //ut:unit_tests passes locally on darwin-arm64 for all three TLS modes: 192 tests, 191 passed, 1 skipped by design (Socketcase.connecttimeout), 1 pre-existing DISABLED test.
• All 9 CI matrix combinations pass, including Windows/MSVC.