Rework the persistence hash and add new scaffold preview option.

[drgrice1]

This replaces all of the previous persistence hash methods with a single peristent_data method. This method both saves to and retrieves from the persistence hash. The first (or second including self in PGcore) parameter is the key in the persistence hash. If the optional second (or third including self in PGcore) parameter is not given then the value of the key for the given label in the hash will be returned. If the second parameter is given then the value of the key in the hash will be saved or updated. Note that if third parameter is given but is undefined then the key will be deleted from the hash. Anything that can be JSON encoded can be stored.

Any front end should save the persistence hash in some way, and send it back each time the problem is rendered. Although the front end reserves the right not to save this if it deems that this is a case that data should not be persistent.

The store_persistent_data, update_persistent_data, and get_peristent_data methods from before still exist in PG.pl (but were removed from PGcore.pl) and they all just call the new persistent_data method. However, they should be considered deprecated, and are only left for backwards compatability. Note that the store_persistent_data method no longer warns if one tries to set the data for a key in the hash that is already set. There was no reason for that warning and probably is why the update_persistent_data method was created that does exactly the same thing except that it doesn't warn and it doesn't return the label that was passed in (why do that anyway?). The whole mechanism was rather poorly designed to begin with.

Add a scaffold preview_can_change_state option that determines behavior when preview is used. The default value is 1, and in that case scaffolds will continue to behave as they currently do. If this option is set to 0, then when an answer preview occurs, the scaffold state will remain the same as before the preview occured. Opened scaffolds will stay open, closed scaffolds will stay closed, and scaffolds that could't be opened still can't be opened. Note this refers to the initial open/closed state when the problem loads, and does not respect opening or closing of scaffolds (that can be opened or closed) by the user.

This uses the persistence hash to store the state. Note that state is really the scores for all answers in scaffold sections. It is important to note that state is usually not saved by the frontend until an answer submission occurs (although it is saved in a hidden form field for instructors), and if there is no state, then it assumes the problem is in its initial state, and uses scores of 0 for all answers.

Note that this replaces #506.

[drgrice1]

Attached is a basic scaffolding problem to test this with: scaffold-preview.pg.txt

With that problem, this pull request, and openwebwork/webwork2#2644 if you are logged in as a student and preview answers the second scaffold will not open and can not be opened. If you submit the correct answer for the first part, then the scaffold will open.

If you are logged in as an instructor and are viewing the problem in a set or in the problem editor and preview answers the second scaffold will not open, but it can be manually opened. If you "Check Answers" then the second scaffold will open if the first answer is correct. However, if you leave the page and return, then that state will not be saved and it will return to its initial state. If you submit answers for the problem in the set, then of course the same think will happen, but now the state is saved. So if you leave the page and return the second scaffold will still be open (assuming you got the first part correct).

[drgrice1]

I should point out that the described behavior only applies to homework sets. In a test scaffolds are all forced open as they always have been.

[drgrice1]

Note that another thing that should be tested is that if you remove the preview_can_change_state option from the problem that the problem behaves the same with develop or with this pull request.