Add a controller instance to state pool; remove prod cases of state.ForModel()

[wallyworld]

Description of change

This picks up on work Menno started to extract controller functionality from state. It's a work in progress.
StatePool gains a controller instance. All uses of state.ForModel() in non-test code is now gone.

Subsequent work will include:

• Add a StatePool to Controller so that State creation always goes via the pool.
• Move all MongoDB and Controller specific functionality onto Controller

QA steps

Run up a couple of controllers
Deploy apps and relate
Migrate model between controllers

[axw]

Given the backwards relationships due to compromises made in this PR, I'm not sure this is a net win. Are we sure that a Controller should contain a StatePool? Can you describe your vision of how it should all hang together in the end?

Some of the ForModel calls can easily be changed to use a StatePool already. I'd prefer if we went through and changed those first, and then look at what's remaining. It might be that we can avoid some of these compromises in the first place.

[axw]

Also, I have some simplifications in the pipeline which will mean fewer StatePools and States being maintained. This may make it easier to get to where we want to be.

[wallyworld]

Reworking the approach to extract system state from state pool and remove the ability of controller to create a new state.