Handle validation of list inputs

[schottra]

flyteorg/flyte#22

There will be a follow-up PR for unit tests. This is against a feature branch, so it doesn't need to be 100% complete to merge

• Changed inputConverters to inputHelpers and moved them into a separate folder with a file for each type. Input helpers export functionality for validating values as well as converting them to ILiterals for submission.
• Separated out the rendering of inputs in the form into a different component.
• Moved input state management out of useLaunchWorkflowFormState into a separate hook. The form state hook will communicate with the input state hook (to get values when submitting) via a ref.
• Added explicit validation before submitting.
• Updated input components to handle rendering errors if they exist
• Added functionality to the form/state to only show errors after the first submission
• Fixed an issue with useFetchable not fully resetting state when its cache key changes. This was causing any submission errors to persist after changing the workflow/launch plan.
• getCacheKey can now also accept an array

Note
The input rendering was moved into a separate component so that I could take advantage of component lifecycle to do something a little strange.
The logic for managing input values and validation gets a lot easier if each input is managed by its own nested state hook. However, the list of inputs is dynamic and changes every time the workflow/launch plan combination changes. This means that something like inputs.map(input => useInputState(input)) will cause problems if the value of inputs changes at all within the same instance of a component.
The solution I landed on was to generate a key value that's based on hashing the array of inputs, and use that with the component that renders the inputs. This has the effect of creating a new instance of the component any time the list of inputs changes. And it means that the map we do will be guaranteed to run on the same list of inputs, in the same order, and result in the same ordering of hooks calls.

[mrmcduff]

Good to have this warning here -- I was trying to think of a way to enforce it on the code side, but you probably don't want any reference to the mount state of the component