double click to open a shared file - #265

Good idea, @tbo47 — quick access to open a shared file is handy. A few things to sort before it'd be mergeable:

1. Don't duplicate the preview logic — reuse it. CSharedFilesCtrl::PreviewFile() is essentially a copy of the existing CDownloadListCtrl::PreviewFile() (DownloadListCtrl.cpp:1382) — same video-player command building, %PARTFILE/%PARTNAME magic, quote-escaping, wxExecute + CTerminationProcess, and the "set a video player" warning. This needs to be a single shared helper called from both, not two copies — otherwise the command-escaping/security handling drifts apart over time. Factor it out (e.g. a free function taking the resolved path + display name) and call it from both controls.

2. Open completed files with the OS default handler, not the video player. Shared files are every type (PDFs, archives, images, …). Right now, if a video player is configured it's used to open everything, which is wrong for non-media. For "open a shared file", completed files should go through the platform default opener (xdg-open / open / shell start) so each type opens in its proper app; the configured video player should only apply to media preview of a partfile — which is exactly what the downloads "Preview" already does. Keeping those two cases distinct also keeps the shared helper clean.

3. Gate it to the monolithic app. SharedFilesCtrl.cpp is also compiled into amulegui (CLIENT_GUI), where the files live on the remote daemon — GetFilePath() / GetTempDir() are the daemon's paths, so opening them on the client machine is meaningless. Wrap the action (and its menu entry) in #ifndef CLIENT_GUI.

4. Prefer the right-click menu over double-click. Launching an external app on an accidental double-click is invasive. There's already an OnRightClick menu here — add an "Open" (or "Preview") item to it, matching the downloads list's existing context-menu pattern. (Keeping double-click as well is a smaller deal, but the menu item is the expected entry point.)