TreeInputType feature request

Problem: There is a contract missing between Subroutine author and SubroutineAction user, which is the TreeInput type. Because the TreeInput type of the SubroutineAction is a dynamic object, the TreeInput property can be defined in various ways. This provides great flexibility, but makes it difficult for the author and user to trust what the expected properties should be.

Feature Suggestion: Add some way to define the expected TreeInput properties inside each individual Subroutine. Forge would then create the specified TreeInput object (either known or dynamic) when calling the SubroutineAction.

Considerations:

• It would be cool if adding a Subroutine TreeInput definition would not require any app code changes. i.e. A config-only change.
• Ideally, known types could also be used in TreeInput. If the application already knows of this type, then it would not require an app deployment. But if it is a new type, then an app deployment would be necessary, which is fine.
• If a TreeInputType is defined as a dynamic object on the tree, then it would be expected that Forge create a dynamic object. Similar to how Forge creates the TreeInput or the Properties property today.
• If the TreeInputType is defined as a knownType however, Forge would be expected to create that type. Similar to how Forge creates an InputType for ForgeActions.

No files, tests, or entry points are identified. Start by locating SubroutineAction TreeInput handling and the existing ForgeAction InputType creation path; define how config-only dynamic and known TreeInput types should be represented and verify both forms are created as specified.