[WIP] Refactoring template driver to dynamically create RAVEN workflows

[j-bryan]

---

Pull Request Description

What issue does this change request address?

#390

What are the significant changes in functionality due to this change

This pull request restructures the templating system used to generate RAVEN workflows.

• The RAVEN template and the template driver are separated into different classes.
• A FeatureDriver class is introduced to define changes to a RAVEN template XML to add a single feature. For example, adding a Grid sampler to the RAVEN XML is done with one FeatureDriver instance, while adding the model used by the workflow is done with a different FeatureDriver.
• FeatureDriver instances can be composed and grouped in FeatureCollection objects.
• The template driver uses feature drivers to edit a template object.
• Edits to the template XML are intended to be strictly additive. One aspect of the previous TemplateDriver implementation that I felt made the current state of the template XML unclear at times was not knowing which nodes were present at any given point in the code due to numerous additions, deletions, and edits made throughout the TemplateDriver. Moving to a strictly additive scheme while starting from a much smaller template XML reframes the template driver's function as adding the desired features to the XML, rather than deleting all other unneeded entities from the XML, as was common practice.
• Addition of a "flat" RAVEN workflow template for specific cases which can be run as flat workflows.

---

For Change Control Board: Change Request Review

The following review must be completed by an authorized member of the Change Control Board.

• 1. Review all computer code.
• 2. If any changes occur to the input syntax, there must be an accompanying change to the user manual and xsd schema. If the input syntax change deprecates existing input files, a conversion script needs to be added (see Conversion Scripts).
• 3. Make sure the Python code and commenting standards are respected (camelBack, etc.) - See on the wiki for details.
• 4. Automated Tests should pass.
• 5. If significant functionality is added, there must be tests added to check this. Tests should cover all possible options. Multiple short tests are preferred over one large tes.
• 6. If the change modifies or adds a requirement or a requirement based test case, the Change Control Board's Chair or designee also needs to approve the change. The requirements and the requirements test shall be in sync.
• 7. The merge request must reference an issue. If the issue is closed, the issue close checklist shall be done.
• 8. If an analytic test is changed/added, the the analytic documentation must be updated/added.
• 9. If any test used as a basis for documentation examples have been changed, the associated documentation must be reviewed and assured the text matches the example.

[PaulTalbot-INL]

Wow, this is quite an effort! Do you have any diagramming or writeup for the logic flow? I think it's starting to make sense glancing over it, but some developer documentation would help get us up to speed on this new structure. Thanks for your work on this!