Centralize logic for describing custom job input types

bespin-api stores information about loaded workflows, including a JSON dictionary of required fields and their CWL types.

This data is consumed by both [bespin-ui](https://github.com/Duke-GCB/bespin-ui/blob/master/app/utils/component-settings.js) and [bespin-cli](https://github.com/Duke-GCB/bespin-cli/blob/69822b74e29ee5dd4881fb1b12c7de781090bd97/bespin/commands.py#L16-L34).

bespin-ui implements logic to render a custom UI that fills in the required fields. bespin-cli implements logic to render a template YAML document, illustrating how to fill in the required fields.

For basic CWL types like `File`, `int`, and `string`, it makes sense that the clients contain logic about how to satisfy those. However, we also use custom types defined in [bespin-cwl/types/bespin-types.yml](https://github.com/Duke-GCB/bespin-cwl/blob/master/types/bespin-types.yml).

For example, we wrote our exome-seq workflow with a custom type, `NamedFASTQFilePairType`. It consists of a `string` (name), and a pair of `File`s. When loaded, bespin-api records the type's name but nothing about the structure. So the responsibility of how to build a `NamedFASTQFilePairType` falls entirely on the clients. Further complicating things, we've [updated that workflow](https://github.com/Duke-GCB/bespin-cwl/pull/60) and are now using a different type, `FASTQReadPairType`, which consists of a `string` and pair of `array`s of `Files`. Neither bespin-api nor bespin-ui currently know what a `FASTQReadPairType` is, so they cannot submit jobs expecting one until they are updated.