itest: Add reusable integration test library crate

[cgwalters]

Extract the test infrastructure pattern shared across bcvk, ostree, composefs-rs, and bootc into a standalone library crate. This follows the direction outlined in bootc-dev/infra repository-structure.md to reduce code duplication for integration testing.

The crate provides:

• Test registration via linkme distributed slices and integration_test! / parameterized_integration_test! macros (no manual test lists)
• Privilege dispatch via privileged_test! and booted_test! macros that auto-dispatch to bcvk VMs when not running as root
• JUnit XML output via quick-junit (set JUNIT_OUTPUT env var)
• A harness runner (run_tests / run_tests_with_config) that ties together libtest-mimic, parameterized test expansion, and JUnit

The integration-tests crate is updated to use itest instead of its own hand-rolled infrastructure. Test function return types are migrated from color_eyre::Result to anyhow::Result to align with the library standard (the tests never used color_eyre-specific features).

Assisted-by: OpenCode (Claude Opus 4.6)

[gemini-code-assist]

Code Review

The pull request introduces a new itest crate for integration testing, featuring automatic test registration, privilege tiers with VM dispatch, and JUnit XML output. The itest crate provides macros for registering tests and supports running tests that require root privileges by dispatching them to a bcvk VM. Review comments suggest improving the error message in the test harness, using a more robust method for creating test name suffixes, and addressing a potential panic in the privilege dispatch logic.

[gemini-code-assist]

Consider adding a more descriptive error message to the map_err closure to provide better context for test failures.

Suggested change

	result: result.as_ref().map(|_| ()).map_err(|e| format!("{e:?}")),
	result.map_err(|e| format!("Test {} failed: {:?}", name, e)).into()

[gemini-code-assist]

Consider using a more robust method for creating test name suffixes, such as URL-safe base64 encoding, to avoid potential collisions and ensure compatibility with various filesystems.

[henrywang]

Thanks @cgwalters!!
We can land this and test it in ostreedev/ostree#3576.