Base enablement to enable a dataset configuration file to be passed in rather than standard args, allow alias's for the folder structure

[rgreenberg1]

Description:
We will need to add support for GuideLLM to take in a dataset configuration profile as an argument (with the details of i/o tokens, for example) that can be used for benchmarking with GuideLLM. These dataset profiles and push them upstream to a folder under GuideLLM to then be pulled in and used as reference datasets for GuideLLM.

User Story:
As a ml developer, I want to be able to provide standard dataset profiles, targeted at different use cases (RAG, Summarization, Chat...) and use that profile as a benchmarking target to better understand what my inference performance will look like for my model/use case when I move to production.

Additional Documentation:

https://docs.google.com/document/d/1Ql6RI3_LbhQxqFCIu_n2A2CewK6OVVFZFYgu4KEjjtw/edit?usp=sharing

Acceptance criteria:
Extend a new argument format for GuideLLM to accept a dataset profile as an argument.
Dataset profile should have the following extensions and formats to be valid as arguments:

• Text - .txt
• Audio - .wav
• image - .png or .jpg

[markurtz]

@sjmonson you're taking this task on, correct?

Aside from that, general thoughts from my side:

1. We should set it up such that the API pathways support passing in configs / aliases for those configs into the APIs. Ex: guidellm --scenario <ALIAS | CONFIG_PATH>.
2. The aliases that are passed in will resolve based on the name of the config that would be stored within the code base such as src/guidellm/benchmark/scenarios
3. Within each config, it contains all required information for fully configuring the scenario including pointing at an HF dataset, locally stored file, a file accessible over HTTP, or synthetic data configuration. For the different dataset pathways, it should support the args for constructing the dataset; ex for synthetic data generation it should contain the source text, prompt tokens with distribution settings. It should specify how to decide on the number of output tokens / output token distribution to use including loading from the dataset, specifying the statistics for the output token distribution, or None. Finally, we should likely include a random seed for reproducibility pathways.

For point 3, a lot of that will become easier with the planned data pipelines rework with expansion to multi modality. Additionally, we'll need to consider what this is going to look like for expansion to multi modal as well.