[test automation] support run tests on config file

[sixianyi0721]

Context

For test automation, the end goal is to run a single pytest command from root test directory (llama_stack/providers/tests/.) such that we execute push-blocking tests

The work plan:

1. trigger pytest from llama_stack/providers/tests/.
2. use config file to determine what tests and parametrization we want to run

What does this PR do?

1. consolidates the "inference-models" / "embedding-model" / "judge-model" ... options in root conftest.py. Without this change, we will hit into error when trying to run pytest /Users/sxyi/llama-stack/llama_stack/providers/tests/. because of duplicated addoptions definitions across child conftest files.

2. Add a config option to specify test config in YAML. (see ci_test_config.yaml for example config file)

For provider_fixtures, we allow users to use either a default fixture combination or define their own {api:provider} combinations.

memory:
....
  fixtures:
    provider_fixtures:
    - default_fixture_param_id: ollama // use default fixture combination with param_id="ollama" in [providers/tests/memory/conftest.py](https://fburl.com/mtjzwsmk)
    - inference: sentence_transformers
      memory: faiss
    - default_fixture_param_id: chroma

3. generate tests according to the config. Logic lives in two places:
   a) in {api}/conftest.py::pytest_generate_tests, we read from config to do parametrization.
   b) after test collection, in pytest_collection_modifyitems, we filter the tests to include only functions listed in config.

Test Plan

1. pytest /Users/sxyi/llama-stack/llama_stack/providers/tests/. --collect-only --config=ci_test_config.yaml

Using --collect-only tag to print the pytests listed in the config file (ci_test_config.yaml).

output: gist

2. sanity check on --inference-model option

pytest -v -s -k "ollama" --inference-model="meta-llama/Llama-3.1-8B-Instruct" ./llama_stack/providers/tests/inference/test_text_inference.py

Before submitting

• This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
• Ran pre-commit to handle lint / formatting issues.
• Read the contributor guideline,
  Pull Request section?
• Updated relevant documentation.
• Wrote necessary unit or integration tests.

[ashwinb]

this seems like a somewhat fragile way to identify the function name. is there no other way?

[ashwinb]

this could be named inference_fixtures so it is clearer?

[ashwinb]

I don't think we need any caching? what was the reason you introduced it?

[ashwinb]

we could put these functions all in the top-level conftest.py?

[ashwinb]

this is a confusing thing -- why are there provider_fixtures within fixtures? also it is unclear why we have a "default_fixture_param_id" and what it indicates. Can you explain a bit?

[ashwinb]

all of these should be Optional and should look like

: Optional[...Config] = None

[ashwinb]

nit: this could be named metafunc_config so it is clearer what it is

[ashwinb]

another nit: the last parameter should be a plural (combinations)

[ashwinb]

looks good, thanks for the iteration. a couple minor nits.