Overhaul logic for generating Calc specifications in automate.py

[spencerahill]

From https://github.com/spencerahill/aospy/pull/155#issue-214872543:

this is well suited for a more OOP approach: a CalcSpec abstract base class, with one implementation of it for each spec that gets passed to Calc. Each implementation would specify how it is to be handled, e.g. where to find its 'default' or 'all' values or what data type to be expected (e.g. dtype_out_time is a tuple that gets permuted over within a Calc, not across Calcs). This would make it easier to, for example, support 'default' and 'all' values for every spec.

I'm now further convinced this is the right approach. Having a CalcSpec class would enable us to cleanly handle:

• What is acceptable user input for that category (e.g. 'all', 'default', or a sequence of Models for models, vs. None or 'vert_int', or 'vert_av' for output_vertical_reductions)
• Logic for handling each accepted input type (e.g. parsing 'all' and 'default' using a parent object, adding an extra list around regions and output_time_regional_reductions so that they don't generate extra Calcs

Eventually I think we could use this to do away with the core/aux spec distinction, and it would help more broadly in our goal to relax the rigid proj/model/run hierarchy, c.f. #111