Fix MSVC handle name collisions

[akalari]

Summary

• map every wrapper-owned OCCT handle type to a collision-proof RustHandle_* C++ alias
• preserve the existing public Rust Handle_* names with CXX #[cxx_name] mappings across all split bridges
• add a Windows MSVC compile lane for the bundled OCCT configuration

Root cause

PR #196 fixed Windows handle-name conflicts in the original monolithic bridge. PR #199 (7e8d78a) later split that bridge and restored names such as Handle_Geom_Surface, Handle_Geom_Curve, and Handle_Poly_Triangulation in the generated CXX boundary.

On MSVC, those names resolve to OCCT compatibility classes emitted by DEFINE_STANDARD_HANDLE, while the wrapper allocates opencascade::handle<T>. The resulting distinct types make wrapper return values incompatible with CXX's generated signatures. This change gives all 16 wrapper-owned handle types one private C++ naming convention that cannot collide with OCCT, without changing their Rust names or high-level API.

Reproduction

At upstream d114250a464d50cde1901743d3bf523a099d6887, a clean cargo check -p opencascade with the default builtin feature, Rust 1.97.1, CMake 4.4.2, and MSVC 14.51 reaches opencascade-sys and fails with:

include/b_rep.hxx(16): error C2440: cannot convert from 'opencascade::handle<Geom_Surface> *' to 'std::unique_ptr<Handle_Geom_Surface>'
include/b_rep.hxx(21): error C2440: cannot convert from 'opencascade::handle<Geom_Curve> *' to 'std::unique_ptr<Handle_Geom_Curve>'
include/b_rep.hxx(30): error C2440: cannot convert from 'opencascade::handle<Poly_Triangulation> *' to 'std::unique_ptr<Handle_Poly_Triangulation>'

CMAKE_POLICY_VERSION_MINIMUM=3.5 was set because the local validation used CMake 4.4.2. The Windows CI step scopes the same compatibility setting to its bundled-OCCT compile.

Validation

• clean cargo check -p opencascade with bundled OCCT on Windows/MSVC 14.51: passed
• cargo clippy --all-targets -- -D warnings: passed
• cargo fmt --all -- --check: passed
• clang-format check for all changed headers: passed
• cargo test -p opencascade-sys -p opencascade: bridge compilation passed, but Windows test executables hit an existing unresolved advapi32 linkage (SetFileSecurityW, AddAce, and related symbols)

The added Windows job intentionally uses cargo check, which compiles every split CXX bridge and the high-level crate without being blocked by that unrelated test-link issue. Existing Linux test coverage is unchanged.