text: Title: [ENH] Design improvement on `config` parameter for FM forecasters
  Body: **Is your feature request related to a problem? Please describe.**
  Currently the below list of forecasters, use the `config` parameter to pass in the model configs.
  
  - TinyTimeMixerForecaster
    ```python
    def __init__(
          self,
          model_path="ibm/TTM",
          revision="main",
          validation_split=0.2,
          config=None, # parameter in question
          ...
      ):
     ```
  - HFTransformersForecaster
    ```python
    def __init__(
          self,
          model_path: str,
          fit_strategy="minimal",
          validation_split=0.2,
          config=None, # parameter in question.
          ...
      ):
    ```
  - ChronosForecaster
    ```python
    def __init__(
            self,
            model_path: str, 
            config: dict = None, # parameter in question.
            ...
        ):
    ```
  
  This seems to be going against `sktime`/`sklearn` design compatibility of having parameters directly passed into the estimator during initialization. Using `get_params` also returns config as a single dictionary and `set_params` cannot be used to set individual config parameters, without passing the entire config dict again, which seems inefficent.
  
  **Describe the solution you'd like**
  Solution 1: Passing all the config parameters directly.
  If the "config" dictionary is required internally, it can be constructed from the parameters. Open to discussion on other possibilities to address this design issue.
  
  Solution 2:
  I believe an hybrid approach would be a good option. Commonly used parameters can be exposed while the rest can be passed in as a separate `config` parameter. This is especially useful when using TSFMs with several config parameters. If a case arises when a parameter passed in the proposed `config` parameter conflicts with the directly passed parameters, then the latter has higher priority.
  
  Solution 3:
  Overidding `get_params` and `set_params`. I am not sure about the feasibility of this.
  