win: retain a shared console session

[radialmonster]

Summary

This implements option 2 from
issue #17193, as
requested by @wpferguson: stop calling FreeConsole() and retain one shared
console session for darktable's lifetime.

Keep darktable attached to one Windows console session so later system() and
popen() children reuse it instead of allocating visible console windows.

The patch extends the minimal FreeConsole() removal for launch states where
darktable starts without a console. In that case, it dynamically uses Windows
11 24H2's AllocConsoleWithOptions() no-window mode. If that export is
unavailable or the no-window allocation fails, it falls back to
AllocConsole(), which retains one visible console for the session.

Caller-supplied disk and pipe standard handles are preserved; ordinary output
continues to use Documents\Darktable\darktable-log.txt.
The retained console is therefore normally blank: this patch does not expose
log messages there. Showing logs in the console would require a separate change
to darktable's existing Windows output-redirection policy.

The application remains a CUI executable. Its manifest preserves the existing
asInvoker and Windows compatibility declarations while adding the 24H2
detached console-allocation policy. This suppresses the initial Explorer console
on supported systems without changing CMD or PowerShell wait behavior.

Related: #17193

Validation

• The production branch completed a fresh MSYS2 UCRT64 BUILD_TESTING=ON
  build. After the final manifest-only formatting amend at 50189c133e, the
  affected targets rebuilt and CTest passed 4/4.
• A final 10-second Shell launch on Windows 11 build 26200 showed zero console
  windows and passed the full dt.control.execute(), os.execute(), and
  io.popen() read/write/lines/status/close/GC contract.
• An explicit final-hash 10-second DETACHED_PROCESS launch also showed zero
  console windows and passed the same contract.
• Separate redirected stdin, stdout, and stderr probes preserved their streams.
• Redirected --version, --help, and --gimp version output and status were
  unchanged, and a CMD probe waited for the CUI process to finish.
• Exact resource extraction confirmed the embedded manifest retains the prior
  execution-level and supported-OS declarations plus the new allocation policy.
• The executable does not import AllocConsoleWithOptions; runtime lookup keeps
  it loadable when that export is unavailable. A forced missing-export run used
  the visible AllocConsole() fallback, showed no child consoles, and passed the
  full command contract.
• The same runtime and manifest semantics passed the complete probe on
  Windows 10 22H2 Pro build 19045 and Windows 11 23H2 Pro build 22631. Both
  systems lack the new export; both loaded the combined manifest, attached the
  fallback console, shared it with a native child, and preserved redirected
  stdin/stdout/stderr. This matrix used the exact packaged 50189c133e
  candidate; each guest extracted the 1,026-byte final manifest and passed the
  full command contract.

All runtime changes in src/main.c are inside its existing #ifdef _WIN32
block. The manifest/resource wiring is inside CMake's existing if(WIN32)
block, and the resource file is Windows-only. Linux and macOS compile none of
the changed runtime or resource code.

Limitations

• Before Windows 11 24H2, the fallback retains one normally blank visible
  console for the darktable session. Closing that console or sending Ctrl+C
  terminates darktable.
• No permanent regression test is included; the Windows console and command
  contracts were validated with the external investigation harnesses described
  above.
• If both the no-window allocation and AllocConsole() fail, later native
  shell children can allocate their own consoles.
• A child that explicitly requests CREATE_NEW_CONSOLE can still create a
  separate console window.

AI assistance

AI assisted with investigation, implementation, and validation.

[lefth]

I'm not a heavy Lua user, but this seems to work well. There are no more console popups at startup or when I run a script like "show in file explorer". My Windows version is new enough that there is no extra terminal window present. My existing VBS launcher (which saves log output to a file) continues to work well.