inconsistency in multiple choice macros about pg HOT 4 OPEN

Here is a sample problem to demonstrate the issue.

DOCUMENT();

loadMacros(qw(
    PGstandard.pl PGML.pl parserPopUp.pl parserRadioButtons.pl parserCheckboxList.pl parserRadioMultiAnswer.pl
));

@a = (3,2,1,0);

$d = DropDown([@a], 3);
$r = RadioButtons([@a], 3);
$c = CheckboxList([@a], [3]);
$rma = RadioMultiAnswer([map{[$_]}(@a)], 3);

BEGIN_PGML

[_]{$d}
[_]{$r}
[_]{$c}
[_]{$rma}

END_PGML

ENDDOCUMENT();

from pg.

One thing I think we should do regardless of settling on consistent default behavior, is give a way for authors to declare that they actually want the other behavior. So I propose:

1. We make PopUp behave like the others: when the answer is specified as a number, and that number is small enough to make sense as an index, then it is interpreted as an index.
2. For DropDown, RadioButtons, CheckboxList, we add an option you can pass, like literal => 1. So for example when "0" is the fourth answer, specifying "0" as an answer with literal => 1 would make the macro understand that the fourth answer is the correct answer. Instead of thinking the 0th index answer is the correct one.
3. Not sure how CheckboxList works right now, but we should make sure that if any of the specified correct answers fails to be a valid index, then all of the specified answers are interpreted as literal. Because why would someone mix indices and literal answers?

from pg.

I am working on a branch that updates parserPopUp.pl similar to how @drgrice1 updated parserRadioButtons.pl. It is necessarily different because with HTML select options, there is no HTML label element for each option (like there is for each radio button). Instead the HTML option element has a value attribute and a label attribute. The text inside the option is sort of irrelevant, except that it is the fallback for value and label when either is missing.

from pg.