Refactor the test examples to parametrize per installer type

[lrandersson]

Description

Solves #1146. The file test_examples.py runs every applicable installer type for an example in a single constructor call and loops over them, which interleaves build/run output and gives no test isolation. When one type fails, the others are masked or skipped, making CI failures painful to debug.

This PR adds the infrastructure to run each installer type as its own pytest item:

• A flag --installer-type to allow testing a specific installer type via the CLI
• Removes the for-loop for iterating over installer types - now uses pytest parametrization (which is based on the installer_types field in each example recipe).
• For demonstrating the changes, this PR migrates only test_example_miniforge (split into miniforge and miniforge-mamba2, each parametrized over its own recipe's types).

The remaining example tests are intentionally left unchanged here to keep this PR small and easy to review. A follow-up PR is expected once this is approved and merged.

Checklist - did you ...

• Add a file to the news directory (using the template) for the next release's release notes?
• Add / update necessary tests?
• Add / update outdated documentation?

[lrandersson]

We can now see in the macOS CI output (as an example):

tests/test_examples.py::test_example_miniforge[sh] PASSED                [ 18%]
tests/test_examples.py::test_example_miniforge[pkg] PASSED               [ 20%]
tests/test_examples.py::test_example_miniforge_mamba2[sh] PASSED         [ 22%]
tests/test_examples.py::test_example_miniforge_mamba2[pkg] PASSED        [ 24%]

[marcoesters]

itypes are the installer types that are read from the construct.yaml file. What this does is ensure that --installer-type is consistent with what you have in the construct.yaml file.

I think what you actually want is to do something like this:

if installer_type:
    info["installer_type"] installer_type
itypes = get_installer_type(info)

[lrandersson]

Great catch, see 6cff5e3.