feat: make training config fields optional (#1861)

# What does this PR do?

Today, supervised_fine_tune itself and the `TrainingConfig` class have a
bunch of required fields that a provider implementation might not need.

for example, if a provider wants to handle hyperparameters in its
configuration as well as any type of dataset retrieval, optimizer or
LoRA config, a user will still need to pass in a virtually empty
`DataConfig`, `OptimizerConfig` and `AlgorithmConfig` in some cases.

Many of these fields are intended to work specifically with llama models
and knobs intended for customizing inline.

Adding remote post_training providers will require loosening these
arguments, or forcing users to pass in empty objects to satisfy the
pydantic models.

Signed-off-by: Charlie Doern <cdoern@redhat.com>

docs/_static/llama-stack-spec.yaml

@@ -6744,10 +6744,13 @@ components:
           type: integer
         max_steps_per_epoch:
           type: integer
+          default: 1
         gradient_accumulation_steps:
           type: integer
+          default: 1
         max_validation_steps:
           type: integer
+          default: 1
         data_config:
           $ref: '#/components/schemas/DataConfig'
         optimizer_config:
@@ -6762,9 +6765,6 @@ components:
         - n_epochs
         - max_steps_per_epoch
         - gradient_accumulation_steps
-        - max_validation_steps
-        - data_config
-        - optimizer_config
       title: TrainingConfig
     PreferenceOptimizeRequest:
       type: object
@@ -7498,7 +7498,6 @@ components:
         - training_config
         - hyperparam_search_config
         - logger_config
-        - model
       title: SupervisedFineTuneRequest
     SyntheticDataGenerateRequest:
       type: object