Refactor Pico project activation around project variants

[gonzalolarralde]

Hello all, I'm working on a proposal to add Swift support to the VSCode extension. While working on that I realized there was an opportunity to make project activation and settings detection a bit more abstract, untangling some of the code in extension.mts while preserving functionality.

I opened the issue #259 to describe the problem, this PR is an implementation proposal. I hope the change size is manageable. I'd be happy to change the approach or break down the PR further if that would help readability.

I've been running a couple test cases and seems to preserve the existing behavior as expected. I verified:

• non-pico projects
• C/C++
• Rust
• Zephyr

Tests included, when applicable: setting board, chip, sdk version, configure CMake, proper handling of non-pico projects.

---

Summary

This PR refactors project detection and activation around a small project-variant interface for the existing Pico project types: C/C++, Rust, and Zephyr.

The goal is not to change user-visible behavior. It is to make the current behavior easier to follow before adding another project type. Previously, activation mixed project detection, selected SDK/toolchain/board parsing, dependency setup, status bar updates, CMake setup, Rust setup, and Zephyr setup in one large flow. That made it difficult to see which parts were shared across project types and which parts were specific to one variant.

This change separates those responsibilities while keeping compatibility with the existing flows.

What Changed

• Added a project variant registry and per-variant implementations for:

  • C/C++ Pico SDK projects
  • Rust Pico projects
  • Zephyr Pico projects

• Moved C/C++ activation behavior into CCppProjectVariant, including:

  • extension-created project detection
  • importable Pico-like project detection
  • selected SDK/toolchain/picotool/board parsing
  • baseline Pico dependency setup
  • managed CMake/Ninja checks
  • Python checks
  • CMake auto-configure / CMake Tools kit handling

• Moved shared Pico dependency setup into utils/picoDependencies.mts so SDK, toolchain, tools, picotool, and OpenOCD setup are not tied to only one project type.

• Kept Zephyr as a compatibility wrapper around the existing setupZephyr flow. This avoids changing the deeper Zephyr setup behavior in this PR while still making activation use the same project-variant structure.

• Updated path/helper commands to resolve chip, target, SDK, and toolchain information through project variant helpers instead of duplicating project-type checks in each command.

Why

This prepares the extension for adding another project type without adding more special cases to activation and command handlers.

The main design idea is:

• project variants determine what kind of project is open
• variants know how to read that project’s selected SDK/toolchain/board/chip values
• common dependencies are installed from those resolved selections
• commands ask the active variant for project facts instead of re-detecting the project type themselves

That makes the relationship between old and new behavior clearer and gives future project types a defined place to plug in.

Compatibility Notes

This PR intentionally preserves the existing behavior for supported project types:

• C/C++ projects still use the generated CMake metadata as the source of SDK/toolchain/picotool selections.
• Rust projects still use .pico-rs and the latest version bundle behavior.
• Zephyr projects still delegate setup to the existing setupZephyr implementation.
• Existing import prompt behavior is preserved for Pico-like CMake projects that contain pico_sdk_init() but are not extension-managed yet.
• Existing command behavior for getChip, getTarget, getGDBPath, compiler paths, SVD path, and Zephyr paths is retained.