Solicit feedback from students, teachers about undo using control-z or command-z

[liammulh]

While testing https://github.com/phetsims/qa/issues/900, I kept thinking it would be nice to be able to go back to the way my circuit was before I made a change.

It seems like this is a common feature of web apps, and something students and teachers might want. Perhaps we could solicit some feedback from students and teachers?

[samreid]

From a user's perspective, it would be nice to have undo/redo in the sim, including buttons in the UI so it is more accessible. Some considerations:

• It should be a full undo/redo stack, so you can go back multiple undos.
• We would need to decide what constitutes an undo-able step. Just topology changes? Closing a switch? Changing a battery voltage? Moving a voltmeter probe?
• If a vertex was selected, then cut--After redo, would the vertex be selected again?
• The implementation would complex, but it would be nice if we could leverage the phet-io circuit state to power it, since that already needs to be a well-established and well-tested feature. This is not the first time we wanted phet-io features in a PhET branded sim. (Presuming that Undo could be state-based rather than a stack of Action items).
• Even if we were able to power it with PhET-iO states, this would be a significant design and implementation undertaking, and it would probably warrant a future iteration priority.

[matthew-blackman]

@samreid @zepumph and I discussed with @arouinfar and agree that this would be a very nice feature, but is outside the scope of the PhET-iO release milestone. We decided to come back to this when we are read to implement save/load in the PhET brand version of the sim as well as via studio.

@samreid proposed simplifying this issue by using PhET-iO states to store/reference the history of the circuit. However, it will likely be more performant to implement this with a stack of user actions, with each action also having an inverse action that is triggered by 'undo'.

[arouinfar]

I agree that this would be a great feature, but it seems best to consider when we are ready to support save/load, #151. Deferring.