feat(nsis): add menuCategory and shortcutName to the NSIS targets

[takke]

Follow-up to #629, as offered there — and to your advice to prefer NSIS over MSI: this removes
the last blocker for migrating our MSI packaging to NSIS.

Problem

The NSIS targets already expose most of electron-builder's installer settings
(oneClick, runAfterFinish, createStartMenuShortcut, …), but not menuCategory /
shortcutName. A start menu group therefore cannot be declared at all: the shortcut always
lands in the start menu root, while the jpackage-era packaging honored windows.menuGroup.

Fix

Add the two remaining CommonWindowsInstallerConfiguration options to NsisSettings and emit
them for nsis and nsis-web:

windows {
  menuGroup = "MyApp"          // acts as the default for nsis.menuCategory, like on MSI
  nsis {
    menuCategory = "MyApp"     // explicit override, wins over menuGroup
    shortcutName = "My App"
  }
}

• Both options default to null (nothing emitted), so generated installers are unchanged unless
  a project opts in — with the same intended exception as the MSI target in fix(msi): forward the Windows installer settings to electron-builder #629:
  windows.menuGroup, the jpackage-era name for the same concept, acts as the default for
  nsis.menuCategory, so projects that declared a menu group get their start menu folder when
  they switch to NSIS.
• electron-builder side: both come from CommonWindowsInstallerConfiguration and are handled by
  the NSIS template (menuCategory creates the submenu, shortcutName overrides the shortcut
  label).

Verified end to end with the patched plugin published to Maven Local: rebuilt our app as an NSIS
installer with only windows.menuGroup declared, and a clean install produced
Start Menu\Programs\ZonePane\ZonePane.lnk (previously the shortcut landed in the root);
uninstall removes the shortcut, the folder and both registry keys.

Tests

• ElectronBuilderNsisConfigTest (new, 5 cases): nothing emitted by default, both options
  forwarded, windows.menuGroup used as the menu category, explicit nsis.menuCategory wins,
  and nsis-web gets the same treatment.
• ElectronBuilderMsiConfigTest: the "nsis target is unaffected by the msi settings" case
  asserted that menuCategory never appears for NSIS; it now asserts the actual concern — that
  msi {} values do not leak into the nsis block.

🤖 Generated with Claude Code

[kdroidFilter]

Great! Thank you so much! And yes, NSIS is much more modern! I'm curious to know if you've stuck with a JVM or switched to the native GraalVM compilation :)

[takke]

Still on the JVM (jlink runtime image) for now — GraalVM native is tempting, but I'd rather let the Nucleus migration settle first. Maybe someday! Thanks again for the quick merges!

[kdroidFilter]

It is perfectly fine to stick with a JVM! Until now, I was much more focused on native compilation rather than the JVM, because a large portion of my users are on Windows 10 (a.k.a. older machines with low RAM), but Nucleus 2.6 is going to refocus on the JVM.

The JVM is an exceptional piece of tech for servers, but it isn't optimized for desktop use at all. For instance, it tends to grab as much RAM as it can just to avoid triggering the GC, and cold boot times on Windows are very long—likely because Windows is generally slow when it comes to compiling. I measure 5 seconds on my high-end rig with a top-of-the-line SSD. I’ve already pushed Project Leyden, which cuts that time in half, but it's still too long for my liking, and the situation is far from optimal.

What I want to do is build an optimized profile for desktop that triggers the GC whenever the window is minimized, loses focus, or even when the machine goes idle (not sure if that's feasible on macOS, and polling is out of the question for me).

Anyway, I could go on for hours detailing everything I have in mind, but feel free to join #nucleus on Slack if you're interested in the topic!