feat: add post_training RuntimeConfig

[cdoern]

What does this PR do?

certain APIs require a bunch of runtime arguments per-provider. The best way currently to pass these arguments in is via the provider config. This is tricky because it requires a provider to be pre-configured with certain arguments that a client side user should be able to pass in at runtime

Especially with the advent of out-of-tree providers, it would be great for a generic RuntimeConfig class to allow for providers to add and validate their own runtime arguments for things like supervised_fine_tune

For example: https://github.com/opendatahub-io/llama-stack-provider-kft has things like input-pvc, model-path, etc in the Provider Config. This is not sustainable nor is adding each and every field needed to the post_training API spec. RuntimeConfig has a sub-class called Config which allows for extra fields to arbitrarily be specified. It is the providers job to create its own class based on this one and add valid options, parse them, etc

[ashwinb]

This is tricky territory and I want to be extremely careful going down this path. At a certain point, the API will stop having meaning and only specific provider combinations will work because client code will be tied to the provider. Why have a generic API at that point? We have kept these escape hatches in the safety.run_shield() method for example, but I think that is an anti-pattern really. I would rather pull up whatever is needed and generalize those pieces and see if we can make them part of the API.

[cdoern]

good point @ashwinb, maybe I could approach a larger refactor to some of the args/class structures of the post training API to better fit more generic implementations whether they be distributed or single node. Implementing some out of tree providers has led me to discover some things I think would be generally helpful, (S3 compatibility, K8s native handling at times, etc)