Extensions of the FittingProblem class

[BradyPlanden]

This is a follow-up to #249 and #223. Specifically, to discuss the addition of the extension classes from the FittingProblem class. My thoughts on child classes for application specific workflows (GITT, POCV, HPPC, etc.) are as follows

• Child classes of FittingProblem should add functionality that we don't want or would be difficult to add in FittingProblem. For example, I think the integration of the pybamm-eis methods would fit this bill, since it would require changing the target fitting object type (complex numbers), model.build and model.simulate call structures.
• Where possible, I think it's better to provide example workflows that show how our core API can be applied to different challenges. This does two important things: it ensures that our core API is flexible and pushes us to provide methods that are robust and general, and it ensures that our end users have more of a hand in developing their workflows. One area I would like to avoid is PyBOP becoming having individual classes for each parameter identification workflow (GITT, POCV, etc.), with users requesting new classes for each new addition in this area. The core API should be robust enough to solve these standard type of battery problems without specialised classes.

This probably extends to other classes as well, and perhaps could be applied across the board to our core API. This might also toe the line between a probabilistic library and an application-specific library, but I suspect that is probably where we want to be.

I'm keen to hear other people's thoughts on the above!

Edit: Cross-linking #124 for reference, although I believe the above supersedes it.