Refactor InstallPageViewModel and add CLI installer

[SticksDev]

This PR restructures the installer to reduce complexity and improve maintainability, and introduces a new CLI-based installer.

The previously large InstallPageViewModel (1,112 lines) has been split into focused service classes responsible for archive extraction, tool setup, VS Code installation, and shortcut creation. These services are registered via DI and shared across entry points, resulting in clearer separation of concerns and improved testability.

A new CLI installer has been added that reuses the same services as the GUI. It supports multiple installation modes via --install-mode:

• all (default): full installation including VS Code
• tools: JDK + WPILib tools only

The CLI also supports offline VS Code installation. If a download fails, it automatically searches for a local VS Code archive and continues with a warning if the hash does not match.

Additional improvements include:

• Unified progress reporting via IProgress<InstallProgress>
• Clear, step-by-step CLI output
• Expanded --help documentation with usage examples

Overall, this change makes the installer easier to understand, test, and extend, while enabling scripted and offline installations through the new CLI.

AI assistance disclosure: Portions of this PR were drafted with the help of an AI language model and reviewed/edited by a human contributor for accuracy and clarity. Please let me know if I missed anything.

[SticksDev]

Adding onto this, to help with review, here’s a quick overview of the larger structural changes and what each new service is responsible for.

• ArchiveExtractionService
  Handles extraction of installer archives with progress reporting. Includes Windows-specific JDK process detection and supports both full and tools-only extraction paths.

• VsCodeInstallationService
  Installs and configures VS Code (portable mode + settings) and installs extensions with progress updates. Also supports online download with offline-archive fallback.

• ToolInstallationService
  Sets up Gradle, WPILib tools, C++, and Maven. Centralizes process execution, error handling, and timeouts.

• ShortcutService
  Creates platform-specific shortcuts on Windows, macOS, and Linux, including desktop and start menu integration where applicable.

Overall, the goal was to make the install flow easier to follow, test, and extend without re-growing the ViewModel.

[SticksDev]

After some debate in Discord, we decided to split the installer into separate projects to better separate shared logic from GUI and CLI entry points and allow independent distribution.

Before

WPILibInstaller-Avalonia/
├── WPILibInstaller-Avalonia/ (single project)
└── IsoCreator/

After

WPILibInstaller-Avalonia/
├── WPILibInstaller.Common/ # Shared installer logic
├── WPILibInstaller.GUI/ # Avalonia desktop app
├── WPILibInstaller.CLI/ # Standalone CLI installer
└── IsoCreator/

WPILibInstaller.Common is a .NET 8 class library referenced by both the GUI and CLI. It contains all models, interfaces, services, utilities, and shared ViewModels, and is now the single home for installer behavior.

WPILibInstaller.GUI (renamed from WPILibInstaller-Avalonia) has been simplified into a pure presentation layer. It contains only Avalonia views, assets, and application bootstrap code, and depends on WPILibInstaller.Common for all installer functionality.

WPILibInstaller.CLI is a new headless entry point built on the same shared services. It supports multiple install modes, all-users installs, offline VS Code fallback, and reports progress using the same IProgress<InstallProgress> mechanism as the GUI.