Modular model building and model updating

[jmlarson1]

Don't pull this in until we discuss it, but I wanted to see a full PR report

[coveralls]

Pull Request Test Coverage Report for Build 9195731513

Details

• 36 of 37 (97.3%) changed or added relevant lines in 2 files are covered.
• 7 unchanged lines in 2 files lost coverage.
• Overall coverage increased (+4.4%) to 100.0%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
pounders/py/pounders.py	11	12	91.67%

Files with Coverage Reduction	New Missed Lines	%
pounders/py/tests/TestPoundersExtensive.py	1	98.51%
pounders/py/pounders.py	6	88.57%

Totals
Change from base Build 8787010077:	4.4%
Covered Lines:	0
Relevant Lines:	0

---

💛 - Coveralls

[mmenickelly]

Do we want to change the order of the formquad arguments to highlight how we hope future model-building routines would be structured? (In particular, vf is non-optional?)

[mmenickelly]

API has not changed, default behaviors are to set model_builder to @formquad and to set Ffun_nargout to 1.

Outstanding problems and things to think about:

• Currently, every model_builder is not even seeing the aux part of the eval_data structure. What I want to do is to have the whole eval_data be passed in so the arbitrary model_builder can have whatever it needs. What this would require, of course, is that formquad immediately just read off the F field of the eval_data and then proceed like usual. Is that okay with us? It's not too unsettling to me.
• Note that we weren't previously using Prior.X_init and Prior.F_init correctly when nfs > 0. Should this be a separate PR? (Yes, but I already did it here) Do we have a test of a nonempty Prior structure in place?
• If we keep going down this road, the output arguments and prepare_outputs_before_return will also want to clean up and output the whole eval_data structure (both the F and aux field)