Add automated Windows release build alongside macOS, and document install options in README

Restructures .github/workflows/release-macos.yml into
.github/workflows/release.yml with four jobs sharing one release:
  - version: computes the vYYYY.MM.DD-<run_number> tag once, shared by
    both platform builds and the final release so they don't drift apart.
  - build-macos: unchanged logic (still build.sh + .app/.dmg packaging),
    just takes its version from the version job and uploads the .dmg as
    a build artifact instead of creating the release directly.
  - build-windows: new. Builds laser_daemon.exe via CMake + Ninja + MSVC
    (ilammy/msvc-dev-cmd) on windows-latest, using a new
    backend/CMakeLists.txt that add_subdirectory()s a libera-laser
    checkout so all of its link requirements (bundled libusb, Winsock)
    come along automatically instead of hand-listing include/lib paths
    like build.sh does for macOS. Packages laser_daemon.exe + the built
    frontend + midi_map.json + the bundled libusb-1.0.dll (from
    libera-laser's vendored helios_dac submodule - Windows has no
    Homebrew-equivalent to install it system-wide) + a new
    packaging/run_windows.bat launcher into a .zip, uploaded as an
    artifact.
  - release: downloads both artifacts and publishes ONE GitHub Release
    with both the .dmg and the .zip attached.

backend/CMakeLists.txt is new and only used by the Windows job - macOS
keeps using build.sh/clang++ untouched. Confirmed via libera-laser's own
CMakeLists.txt/CI that CoreAudio/CoreFoundation/AudioToolbox are only
linked `if (APPLE)` (so nothing macOS-specific leaks into the Windows
build) and that Windows support is already exercised by libera-laser's
own tested CI (windows-latest + LIBERA_USE_BUNDLED_LIBUSB=ON), which is
what our CMakeLists.txt sets automatically for WIN32. laser_daemon.cpp
itself already guards CoreMIDI behind `#ifdef __APPLE__` with a graceful
"MIDI control disabled" fallback otherwise, so no source changes were
needed there for Windows - REST/WebSocket/laser output/cues all work
the same.

Also documents this in DEVELOPER.md under a new "Building for Windows"
section, and adds an "Installing" section to README.md up front covering
all three ways to run BeamCommander3: the macOS .dmg, the Windows .zip,
and building/running from source via start.sh - replacing the old
step 1 of "Using the show" that only mentioned start.sh.

Not yet locally testable end-to-end (no Windows machine available) -
relying on CI to build it and will verify the published artifact's
structure/binary validity after the workflow runs.

Author: oliverbyte