feat: multiple performance configs in a submission config

Each submission config contains accuracy config and a single performance config. When sweeping through concurrencies, requiring an accuracy run for each concurrency value increases runtime, especially when the accuracy dataset takes similar/longer time compared to the performance dataset. Propose to allow multiple performance configs within a submission config.
Before:

  load_pattern:
    type: "concurrency"
    target_concurrency: 512

After:

  load_pattern:
    type: "concurrency"
    target_concurrency: 64,128,256,512

This allows amortization of doing accuracy runs and encourages using a single endpoint config for different concurrency levels.
Several possible considerations:

1. target concurrency values are strictly ascending
2. Requests for a new concurrency are issued after requests for the current concurrency value are all received (not issued).
3. Accuracy run uses the highest concurrency

No files or tests are named. Start by tracing submission config handling and the load_pattern execution path, then inspect how accuracy and performance runs are coordinated. Done means a submission config accepts multiple target concurrency values and follows the stated ordering, request-draining, and highest-concurrency accuracy considerations.