Support building bundled HPTT with MSVC on Windows

[IvanaGyro]

Problem

Cytnx currently disables HPTT in its Windows Pixi configurations because the bundled HPTT project cannot complete an MSVC/Ninja build.

thirdparty/hptt/CMakeLists.txt builds both hptt_static and hptt_dyn and assigns both targets OUTPUT_NAME hptt. On Windows, the static target produces hptt.lib, while the shared target's import library is also named hptt.lib. Ninja therefore sees multiple rules generating the same output.

Cytnx itself links only hptt_static, so disabling all HPTT support should be avoidable.

Investigation result

Letting CMake choose the library suffixes alone does not solve the collision. CMake already applies the correct MSVC artifact model:

• a static library is an ARCHIVE artifact ending in .lib;
• a Windows DLL's import library is also an ARCHIVE artifact ending in .lib;
• with the shared OUTPUT_NAME hptt, the existing Ninja graph therefore contains both hptt/hptt.lib and hptt/hptt.dll hptt/hptt.lib.

The useful form of “let CMake decide” is to stop forcing the same basename on Windows:

if(NOT WIN32)
  set_target_properties(${target} PROPERTIES OUTPUT_NAME hptt)
endif()

CMake would then produce hptt_static.lib, hptt_dyn.dll, and hptt_dyn.lib on Windows, while Linux and macOS retain libhptt.a plus libhptt.so/libhptt.dylib.

A narrower alternative is to keep the DLL named hptt.dll and set only the shared target's ARCHIVE_OUTPUT_NAME to hptt_dyn. The global CMake suffix variables and target IMPORT_SUFFIX should not be overridden.

Remaining MSVC work

Fixing the output collision exposes additional source-level portability failures verified with MSVC 19.44:

• __restrict__ is not accepted by MSVC in include/transpose.h and src/transpose.cpp; use a project portability macro that maps to __restrict under MSVC.
• INLINE has no MSVC definition in include/macros.h; map it to __forceinline.
• variable-length arrays in src/transpose.cpp (currently around lines 755–758 and 1729) are not standard C++ and fail with C2131/C3863; replace them with std::vector or fixed-size standard containers where possible.
• the optional AVX path uses -mavx; MSVC needs /arch:AVX.
• if the shared target remains enabled, it also needs exported symbols (export annotations or WINDOWS_EXPORT_ALL_SYMBOLS) to produce a usable DLL/import library.

Because embedded Cytnx links only hptt_static, the smallest complete integration may be an upstream HPTT_BUILD_SHARED option that Cytnx sets to OFF. That avoids the shared-library naming/export work, but the restrict, inline, and variable-length-array fixes are still required.

Preferred implementation order

1. Add upstream HPTT_BUILD_SHARED (default ON) and build hptt_dyn only when enabled.
2. Set it to OFF from Cytnx's bundled-HPTT integration.
3. Add MSVC portability macros and replace the variable-length arrays.
4. Update the Cytnx HPTT submodule.
5. Re-enable HPTT in the Windows Pixi configurations and validate incrementally.

Acceptance criteria

• USE_HPTT=ON configures and builds with MSVC 2022 and Ninja;
• hptt_static and the shared-library import library never claim the same output path;
• HPTT source compiles without relying on GNU-only restrict/inline syntax or variable-length arrays;
• tensor permutation tests pass on Windows with the HPTT path enabled;
• installation/export and the downstream find_package(Cytnx) test still work;
• standalone shared HPTT remains usable when HPTT_BUILD_SHARED=ON, if that option is implemented;
• Linux and macOS HPTT builds and artifact names remain unchanged.

Found while preparing the Windows build in #1110. Investigation update performed by OpenAI Codex with MSVC 19.44 and the existing incremental MSVC/Ninja build tree.