namespace for control variables, refactor getControls()

[sbenthall]

A parallel issue to #761.

Currently, in getControls(), control variable values are assigned to the object as attributes.

In line with architecture changes like #760, this should become a dedicated collection, e.g. self.controls as a dictionary.

[sbenthall]

I want to note that while I think having a separate namespace for states, control, and shock variables is the right first next step to be consistent with the current design, I'm not as certain this is the right way to organize things longer term.

As @llorracc has observed, there's times at which the status of a model variable seems to change, or else is superficial.

[llorracc]

#836 only addresses states; this is the corresponding issue for controls

Related to need to rethink relationship between states, controls, and shocks

[sbenthall]

I'm looking at this now.

In the basic ConsIndShockModel case, two values are set in getControls().

cNrmNow is clearly a control variable.

I think MPCnow is not a control variable, but rather is something that's being computed out of economic interest. It's an 'epiphenomenal' property, something that depends on the action taken but has not endogenous effect on the system.

Is that interpretation correct?

It would be nice if there was a namespace for these properties. They are not really the same thing as model variables.