Feedback on naming of Tool parameters

I had a chance to talk with @deep-rloebbert and gather some feedback on the recent of Agent and the changes that came with Tools (e.g. adding outputs_to_string).

The naming of outputs_to_state and inputs_from_state resonated well with him, but there were a few suggestions for improvement.

• Similar to how we have named the variables in SuperComponent input_mapping and output_mapping, @deep-rloebbert would find the names inputs_from_state_mapping and outputs_to_state_mapping more clear and consistent between our abstractions.
• For the outputs_to_state_mapping a suggestion for rearranging the how the dictionary is passed to it:
  • Rename source to state_key to indicate where the output should go into state
  • Put the name of the final output first
  • Rename handler to aggregation_handler to make it clearer that the handler function handles aggregation

# Before
outputs_to_state_mapping:
  documents:
    source: documents_super_output
    handler: None

# After
outputs_to_state_mapping:
  documents_super_output:  # <-- Put the name of the final output first
    state_key: documents  # <-- Rename source to state_key
    aggregation_handler: None  # <-- Rename handler to aggregation_handler

• Preference on renaming outputs_to_string to outputs_to_result_mapping since the string naming is confusing and unclear. So the hope here is that result_mapping better indicates how we'd like to transform the output of the tool into the final "result" which will be passed back to the LLM.

# Before
outputs_to_string:
  source: result
  handler: None

# After (can either pass only a string or dict
outputs_to_result_mapping: result  # <-- Add an option to just pass a string for convenience
# or
outputs_to_result_mapping:  # <-- current version that accepts a dict
  source: result
  handler: None

No files or tests are named. Start by reviewing the Tool and Agent parameter handling alongside the SuperComponent input_mapping and output_mapping abstractions; determine the migration and compatibility scope for the proposed names and mappings, then define tests that verify the revised configuration forms and final LLM result behavior.