Decouple Jobs from Workflows and Nodesets

Allow Workflows and Nodesets to be definable outside of jobs, and turn Job definitions into a composition of: Nodeset(s), Workflow, job parameters/options.

Similar issues/requests: #70, #99, #185, #413, #414, #419, #470

Introduce "Named workflows" = stored workflows that can be created independently of a Job.
existing Jobs will use "anonymous"/internal workflows. Workflows will be organized/shared almost identically to the way Jobs are now, but will not have associated Nodesets or other execution parameters (threadcount). They can define Options which declare required/optional input parameters.

Introduce "Nodesets" = stored node filter sets, similar to user-specific stored Node filters now. They define a dynamic (filter-based) or static (list of names) set of Nodes. [Optional "Smart" nodesets could combine other nodesets]

Introduce mechanism for "Workflow References", which execute another stored workflow, and can pass in or set the Nodeset to execute. This may supplant/replace "Job references", or Job References may still remain.

The new "Job" definition will consist of:

• a workflow to execute
• node set to execute on
  • option to allow overrides or alternate node sets which are selectable by the user at execute time?
  • Job execution parameters: parallel/threadcount?
  • Job options(?) additional user input options?

Considerations:

• Introduces possibly more Domain classes and more complexity
• Requires new format definitions for import/export of Workflows and Nodesets independently of Jobs. Job definitions need update to support this.
• New API endpoints: CRUD,import/export of Workflows and Nodesets
• New GUI work: browse, CRUD of jobs/workflows/nodesets. Nodeset GUI could be merged with or supplant the current Node filters GUI which needs updating. Workflows GUI would be mostly similar to old Jobs GUI. Jobs GUI would have to be updated to support this.
• Core execution engine work: Not much, the internal system already only executes with such a composition of objects (exec params, workflow, nodeset), so we are merely updating the App/storage layer.
• options: each "workflow" will define necessary input options. Should a Job's options then just be the set of all options defined by the Workflows it uses? Should there be a way to define a custom set of input options, and provide custom defaults for workflow options? This would provide greater user choice.