Overhaul flow generation modifiers for increased flexibility.

Current modifiers from the docs:

@generate_flow_definition(modifiers={
   'generate_metadata': {'endpoint': 'funcx_endpoint_non_compute'},
   'publish_to_search': {'endpoint': 'funcx_endpoint_non_compute',
                         'payload': 'generate_metadata'}
})
class ProcessData(GladierBaseClient):
    gladier_tools = [
        'mytools.TransferData',
        'mytools.processing.ProcessData',
        'mytools.processing.GenerateGraphs',
        'mytools.processing.GenerateMetadata',
        'mytools.processing.PublishResults',
    ]

There are three main problems with the old style:

They specify modifications to functions, not Globus Flow states. Functions typically map to Flow states for simple flows, but this isn't always the case
It is not possible to duplicate tools with modifiers, as it's ambiguous which function would apply to which flow state.
It is not possible to modify values in non-funcx states, which are not attached to functions

This newer style would allow for increased flexibility to modify arbitrary values in arbitrary states, and allow for modifying duplicated tools. See below:

@generate_flow_definition(modifiers={
   'TransferData.source_endpoint.$': '$.input.my_source_endpoint',
   'ProcessData.Parameters.tasks.endpoint.$: '$.input.my_funcx_endpoint',
})

The newer style is flat and specifies exact values within the flow data to change. This allows for greater flexibility which was lacking from before, with a drawback of slightly increased complexity. Users will need to know the full ProcessData.Parameters.tasks.endpoint.$ path to set within the FuncX input data, for example.

To help lower the complexity, the error checking needs to be more robust and display any missing info that isn't readily available. One specific problem is Tool names vs Flow State Names. Tool states don't necessarily map to Flow states like they do above, so it would be easy for users to get confused on what exactly they need to specify as a modifier.

For example above, the flow state for processing may be called "RunAnalysisTool" instead of "ProcessData". If a user lists a flow state that doesn't exist, the Gladier Client should list all tools with corresponding flow states so the user doesn't need to introspect each tool to find the correct state. Something like:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
Exception "ProcessData" is not a valid Flow State. Please choose a Flow State from the tools below: 
{'my_tools.processing.processData': ['RunAnalysisTool'],
 'mytools.TransferData': ['TransferData'],
 'mytools.processing.GenerateGraphs': ['GenerateGraphs', 'TwittleThumbs', 'KickComputer'],
 'mytools.processing.GenerateMetadata': ['GenerateMetadata'],
 'mytools.processing.ProcessData': ['ProcessData'],
 'mytools.processing.PublishResults': ['PublishResults']}

globus-gladier / gladier

Overhaul flow generation modifiers for increased flexibility. #93