a not-too-general value backwards induction algorithm built on DBlocks

[sbenthall]

This PR aims to provide a general backwards induction algorithm that operates on a single DBlock.

It simply arranges the pieces that come with the DBlock (decision value function, arrival value function), in a sensible way, with an optimization over the action space to find the best action at each point in the state grid.

While the algorithm is not as good as FOC or EGM methods, I'm doing this for several reasons:

• As a way to work out the API design for solution algorithms more generally
• As a way to put pressure on the HARK 1.0 proto-language to include details that have been missing (such as bounds on actions)
• As a way to demonstrate the way discretization of shocks is used for solutions, so that I can build a demo of how the same discretization can be used for solution and simulation. (This is a target for my upcoming SciPy deliverable)

The first commit of this PR just sketches the algorithm out, but it isn't tested.

One question is how to design this so that it is more agnostic to different optimizers. I know @alanlujan91 is keen on estimagic.

• Tests for new functionality/models or Tests to reproduce the bug-fix in code.
• Updated documentation of features that add new functionality.
• Update CHANGELOG.md with major/minor changes.

[sbenthall]

Clarifying that by "general", I mean "not-too-general". A "not-too-general" solver, by my definition, is a solver that:

• contains no specific model data
• but only works when certain conditions on the model provided as input are met.

This is in contrast with a "model specific solver", which is what most HARK models currently have; these solvers contain specific model data.

[sbenthall]

@mnwhite @alanlujan91 I wonder what you think about this way of introducing upper/lower bound information on control variables.

[alanlujan91]

I think this looks good.

If we wanted to differentiate between a fixed (real number) upper bound, and a functional upper bound, we could use the term upper_envelope for a function/lambda.

[sbenthall]

This PR now includes:

• setting upper and lower bounds on a control variable programmatically
• passing those bounds through to the VBI solver
• an automated test showing proper functionality on the normalized consumption block for the last period (solves for consume all resources).

This PR is now ready for review. Requesting review from @alanlujan91 or @mnwhite

As I mentioned in the original post for this PR, my next step, building on this PR, is a demonstration of a configuration that will use:

• a 'true' model definition
• a discretization of the model
• using the same discretization for both solving and simulation

[sbenthall]

One thought on how to improve this PR:

• the value backwards induction algorithm implementation currently assumes one control variable in the block ('stage'). Of course, that's not fully general.
• fixing it so that it works when there are no control variables is trivial to implement, and would illustrate how the '2 or 3 value function?' question can be easily handled with contextual information. No big deal
• Working with multiple control variables is a little trickier but in principle doable. I'd like to leave this out of scope for this PR.

[sbenthall]

Recent changes add handling and tests for cases where the stage has zero control variables.

[sbenthall]

This is now ready for review again.