Clean up options code and better error messages

[tnelson]

Right now adding a new option requires changes in several places:

• the Options struct defn
• the init-options define
• state-set-option (in 2 places!)
• get-option

We did this for 2 reasons:

• I couldn't figure out how to cleanly update struct values without knowing the field name at compile time (maybe switching to macros could fix this?)
• It enables some type-checking so students who try to use an unknown field, or give a wildly wrong value, will receive error messages rather than silent failure.

The errors still aren't great because we don't catalogue the actual set of valid values. E.g., logtranslation can meaningfully be 0, 1, or 2 -- but not 100.

[tnelson]

Also note word-separation is inconsistent. Some options run words together (logtranslation) and others use underscores.
Dashes are unfortunately not usable in identifiers in #lang forge, since - means minus and we decided not to adopt Pyret-style whitespace.

[tnelson]

Maybe it'd have been better to have an option 'temporal, an option 'target etc. rather than one 'problem-type option. Discuss.

[sorawee]

I couldn't figure out how to cleanly update struct values without knowing the field name at compile time (maybe switching to macros could fix this?)

That sounds like a wrong way to use struct... If it's quick to elaborate the problem, could you do that? But if it will take long time, it's probably not worth it then.

[tnelson]

We have a struct Options that comprises all the Forge options (core minimization setting, etc. etc. etc.)
To change an option, we call struct-copy. E.g., (struct-copy Options options [solver value]), where options is the identifier for the current options struct, solver is a field name, and value is an identifier bound to the new value.

The problem is that I can't call (struct-copy Options options [key value] where key is an identifier bound to a field name. There's no field named key!