Windows: fix command-line file opening and Unicode path support (#30)

[tjfunction412]

Fixes #30.

This PR addresses two related Windows bugs and bundles a small build improvement.

Fix 1 — Command-line file opening (issue #30)

WinMain in src/main.cpp received lpCmdLine but never parsed it. The non-Windows main(argc, argv) had an argv loop calling CsvApplication::droppedFileCB, but it was excluded from _WIN64 builds via #ifndef. As a result, files passed via Windows Explorer file association or Tablecruncher.exe path/to/file.csv were silently dropped and an empty "Empty 1" window opened instead.

Fixed by parsing the wide command line with CommandLineToArgvW and routing each argument through Helper::ws_to_utf8 → CsvApplication::droppedFileCB, matching the existing non-Windows behavior. CommandLineToArgvW is the right entry point here: lpCmdLine and __argv are ANSI and would lose Unicode characters to the active codepage.

Fix 2 — Unicode path support throughout file I/O

Helper::ws_to_utf8 and Helper::utf8_to_ws were declared in helper.hh but never implemented. Added Windows implementations using WideCharToMultiByte / MultiByteToWideChar with CP_UTF8.

Tablecruncher's file I/O used std::ifstream::open(const char*) and std::ofstream(const char*, ...) with UTF-8 std::string paths. MSVC interprets these narrow paths as the active ANSI codepage, not UTF-8, so any filename outside that codepage failed to load even after Fix 1 delivered it correctly. This broke Unicode filenames passed via Explorer (Cyrillic, CJK, many Latin-1 supplement characters).

Added Helper::openInputStream / Helper::openOutputStream wrappers that transcode UTF-8 paths to wide on Windows and use the MSVC wstring overloads, while keeping the narrow path on POSIX. Routed all five file-open call sites through the new helpers:

• csvwindow.cpp load path
• csvapplication.cpp two existence checks (split CSV, save dialog)
• csvtable.cpp two save paths (save CSV, export JSON)

Fixed Helper::getFileSize similarly (stat → _wstat64 on Windows). Replaced std::filesystem::path(std::string) calls in the recent-files loader and the menu-label code with std::filesystem::u8path, which correctly interprets the input as UTF-8 across platforms.

Bonus — Embed icon at build time

The build previously relied on a post-build Resource Hacker step (scripts/buildwin.bat) to inject the application icon. This makes building from source without the Inno Setup release workflow produce an icon-less binary. Added a minimal assets/windows/app_icon.rc and wired it into CMake via enable_language(RC), so MSVC's rc.exe embeds the icon during the normal build.

The Resource Hacker call in buildwin.bat is left in place to avoid scope creep but is now redundant for icon embedding.

Testing

Built with Visual Studio Build Tools 2026 (MSVC 14.51, x64) and FLTK 1.4.5 on Windows 10. Manually verified:

• Empty launch — still shows a single "Empty 1" window (regression check)
• ASCII path via command line — opens correctly
• Path with spaces via command line — opens correctly
• Multi-file via command line (a.csv b.csv c.csv) — first file populates the initial window, subsequent files open new windows
• Latin-1 supplement filename — opens correctly
• Cyrillic filename — opens correctly
• CJK filename — opens correctly
• File association double-click on a CJK filename via Explorer — opens correctly
• File → Save As with a Cyrillic filename, close, reopen via double-click — full round-trip works

Compatibility

Behavior on macOS and Linux is unchanged. All Windows-specific code is guarded by #ifdef _WIN64 (matching the existing pattern in the codebase). The new helper functions have non-Windows paths that preserve the prior narrow-string behavior.