Unwind type dependencies in initialization

[mnwhite]

This issue has been reproduced from communications among team members. Unlike normal issues, this communication happened after the programming work had been done, to document that it was done. So it's an "issue" that already has a corresponding PR.

---

MNWHITE writes:

The gist is that literally all __init__ methods for AgentType subclasses are now removed. They all use the same init method inherited from AgentType itself, with no special code being run. Subclasses now have a standard default_ dictionary with entries for parameters and solver, which is automatically used during initialization. All of the instance-specific time_inv and time_vary material has been removed, so that they should be more or less static (but still defined at the instance level, copied from class-level time_inv_ and time_vary_. Solution objects that are unpacked will still be added to time_vary, I think.

To improve debugging capability, it's now possible to pass the argument construct=False to the init method, which prevents any of the constructor functions from being run. As is, if you have a faulty constructor, or pass invalid inputs for a constructor, an AgentType might fail to initialize at all because an error is thrown during its call to construct. That prevents the user from inspecting the work that the instance was able to accomplish before that error. With the new functionality, a user can tell their AgentType instance "here are some parameters, but don't try to do anything with them; please just exist." They can then call construct sequentially on individual constructed inputs, inspect the results, and see how the error is occuring.

To the long-running problem of students / new users changing (e.g.) PermShkStd and then being surprised when the solution doesn't change when they solve the model again, we can add a couple lines that add similar functionality. See the separate work item I'm adding in a moment for the more comprehensive solution to that problem.

This work has been completed in #1529 , with a small extension in #1530

[mnwhite]

Those PRs also take care of another very closely related work item: making sure all appropriate model objects are built with a constructor function and not an class method. I.e. they can all be changed without making a new subclass.