Add version handling for workflow steps to support breaking changes while maintaining backwards compatibility

[ctate]

Problem:

Currently, when contributors need to make breaking changes to a step's input or output schema, there's no way to do so without breaking existing workflows that use that step. Users who have already built workflows with the current step implementation will experience failures if the step interface changes. This creates a dilemma: either we never make breaking changes (limiting evolution), or we break existing workflows (poor user experience).

Scope:

This affects all steps across all integration plugins. Each step currently has:

• A step function (e.g., sendEmailStep) with defined input and output types
• An action definition in the plugin registry that maps to the step
• Workflows stored in the database that reference these steps by action ID

Requirements:

1. Contributors must be able to create new versions of steps when introducing breaking changes to inputs or outputs
2. Existing workflows must continue to execute using the step version they were originally created with
3. New workflows should default to using the latest version of a step
4. The system must be able to route step execution to the correct version based on the workflow's requirements
5. Both old and new versions of a step must be able to coexist and execute in the system

Constraints:

• Existing workflows in the database should not require migration when new step versions are added
• The solution should work with the current plugin architecture and step registry system
• The step discovery and auto-generation system (scripts/discover-plugins.ts) should continue to work or be adapted accordingly