Best practices on managing state during `explain` calls

[jklaise]

Currently we don't have guidelines for how to manage the state of an explainer object, especially during explain calls. An explain method may be very complex internally, calling a bunch of different methods or functions, so state is often set using various attributes to keep track of calculation results. However, this can be problematic for several reasons:

• The attribute names are not consistent, it is not clear what is meant to be public/private or what is set during initialization or fit vs explain.
• Any state set (and not cleared) during explain will by definition be related to something we just finished explaining, so it doesn't feel right to hold onto this state after explain call finishes
• Arbitrary state can introduce difficulties serializing the explainer.

On the other hand, it's not clear what the best patterns of managing state in explainer objects could be. A broader move towards functional programming patterns may help.

[adriangonz]

Following the initial exploration done in PR #460, we identified that this task may need a explainer-by-explainer approach. Therefore, we've decided to split this into smaller tasks to assess how this can be done for each explainer.

Based on the above, this task also includes now #462 and #463 as sub-tasks.