Implement proper custom typing in Flytekit to improve UX and visibility in UI for complex classes such as HyperparameterTuningJobConfig

[bnsblue]

Currently users need to call to_flyte_idl() for complex classes such as HyperparameterTuningJobConfig in user code, which is not ideal:

hpo_inputs={
    ...
    "hyperparameter_tuning_job_config": HyperparameterTuningJobConfig(
        hyperparameter_ranges=ParameterRanges(
            parameter_range_map={
                ....
            }
        ),
        tuning_strategy=HyperparameterTuningStrategy.BAYESIAN,
        tuning_objective=HyperparameterTuningObjective(
            ....
        ),
        training_job_early_stopping_type=TrainingJobEarlyStoppingType.AUTO
    ).to_flyte_idl()
   ...
}

We should implement proper custom typing in Flytekit to get rid of this.

Two approaches

1. Create my own type and serialize it

Int, Collection, String => return a struct (proto struct)

2. Use proto as binary

Take a proto -> serialize it
binary->struct

[EngHabu]

• Introduce SDK Proto type (similar to Types.Proto) that serializes protos into structs and can be used by users for any proto.
• Migrate HypeparameterTuningJobConfig type to using the struct version to enable visualization of inputs in Flyte UI
• Make a corresponding change in HPO Golang plugin to fallback to binary proto deserialization for backward compat.
• Override call function in HPO Task to clear up the usage docs so that IDEs do not infer the wrong signature and complain about passed inputs.
• Move parameter ranges out of the config object as inputs of type Proto

[EngHabu]

Flytekit:

• Introduce Types.GenericProto to represent Protos using structs (for better Fyte Console Visibility)
• Use structs for custom sagemaker types (instead of binary protos)
• Accept FlyteIdlEntity in Types.GenericProto constructor to get rid of .to_flyte_idl() requirement
• Use Types.GenericProto to represent ParameterRange proto as a Flyte Type that can be used for inputs/outputs
• Introduce tunable_params for HPO job, the list of params will then exist as explicit inputs of the generated HPO job.
• Override call function in HPO Task to clear up the usage docs so that IDEs do not infer the wrong signature and complain about passed inputs.
• Update and fix unit tests
• Update a functional test WF to use the new pattern and verify an end-2-end WF works.

HPO Go-Plugin:

• Accept struct input and fallback to binary proto (for backward compat)
• Parse other inputs of type ParameterRange and pass them to HPO jobs as hyper parameters