refactor(build): migrate platform options from Cargo features to Kconfig

[dallasxy]

As hvisor has grown, the flat feature list is no longer expressive enough to describe platform options reliably (dependencies, mutual exclusion, and arch-specific menus). Kconfig provides a single, reviewable configuration surface for local builds, CI, and rust-analyzer.

This PR replaces per-board Cargo features and platform/.../cargo/features with a Kconfig-based configuration flow aligned with common kernel/firmware practice. Platform features are described by CONFIG_* symbols, materialized into a generated root .config, and turned into Rust conditional compilation via build.rs and kconfig/cfg_map.toml.

The branch also includes Jenkins/CI housekeeping (isolated workspaces, GitHub Checks per matrix cell, make defconfig in the build matrix) so CI matches the new build entry points.

Closes: #318

[Inquisitor-201]

Thanks for this PR — migrating to Kconfig is a well-established practice and it looks like a lot of work went into it. I'm trying to understand the motivation and trade-offs better:

1. The current cargo/features approach is simple and the team is already familiar with it for adding new boards. What concrete issues have you encountered that Kconfig would help with? Feature dependency/mutual-exclusion enforcement? Or something else?

2. After this merge, will make BOARD=qemu-gicv3 continue to work, or do contributors need to switch to make defconfig && make?

3. Noticed tools/kconfig/vendor/ includes vendored .whl files — just curious, are these needed for offline builds, or could they be installed from PyPI instead?

[dallasxy]

Thanks for this PR — migrating to Kconfig is a well-established practice and it looks like a lot of work went into it. I'm trying to understand the motivation and trade-offs better:

1. The current cargo/features approach is simple and the team is already familiar with it for adding new boards. What concrete issues have you encountered that Kconfig would help with? Feature dependency/mutual-exclusion enforcement? Or something else?
2. After this merge, will make BOARD=qemu-gicv3 continue to work, or do contributors need to switch to make defconfig && make?
3. Noticed tools/kconfig/vendor/ includes vendored .whl files — just curious, are these needed for offline builds, or could they be installed from PyPI instead?

Motivation: The old cargo/features model had no dependency/mutual-exclusion checks, split config across Cargo.toml, per-board cargo/features, and Makefile wiring, and rust-analyzer often drifted from real build flags. Kconfig adds depends on/select/choice, reviewable per-board defconfigs, and a single path via cfg_map.toml + build.rs → rustc --cfg.

Workflow: make BOARD=qemu-gicv3 still works. ensure_config auto-runs defconfig when .config is missing or ARCH/BOARD changed — no manual make defconfig && make for normal builds. Explicit defconfig is only needed for bare cargo build or intentional config refresh.

Vendor wheels: Agreed — the vendored wheels should be removed from the repo.

[Inquisitor-201]

Noticed that depends on in Kconfig. This blocks it on x86_64 — is that intentional? The PCI virtio code uses MSI-X and doesn't seem to have a GIC dependency. Kconfig:180

[dallasxy]

Noticed that depends on in Kconfig. This blocks it on x86_64 — is that intentional? The PCI virtio code uses MSI-X and doesn't seem to have a GIC dependency. Kconfig:180

Yes, currently this feature actually relies on the GIC's MSI-X mechanism.

[liulog]

Looks good!