do not add separators to PSET file (and avoid historical collisions)

[dndrks]

tonight, i realized that adding separators to the lookup table in #1584 means they get collected by the PSET writer. this is generally fine, since they don't have a :set action, but this syntax situation would result in an error if a PSET were saved and subsequently loaded for a script with conflicting parameter IDs:

function init()
  params:add_number('velocity', 'velocity', 0, 127)
  -- [...] some other params [...]
  -- assuming another section of the params wanted to use 'velocity' to demarcate a set of actions,
  --   but the author didn't provide a unique ID:  
  params:add_separator('velocity') 
end

the resulting PSET file would look like:

-- my_PSET
[...] SYSTEM PARAMS [...]
"velocity": 43
[...] some other params [...]
"velocity": 

and the PSET read would attempt to re-set the number-based velocity to '' once it got to the second separator-based velocity, creating an error due to clamping a number with a string.

this PR corrects the inclusion of separators for new PSETs, as well as a mechanism to avoid reading values to parameters which have already been restored (to address PSETs which would have been made since 220802 was released). lmk if there's a more preferable way to address this and very sorry for not catching it before!