Closes: #XXXX
Refs: #1710

## Description

#1710 enhanced `getEnvironmentOption`
with an optional third argument listing all the other allowed choices
aside from the default choice. Previously, we had only manual code to
detect and complain of unrecognized environment option values. #1710
provides a more declarative form, and reuses the
checking-and-complaining logic. However, following #1710 we did not
retire much of the previous ad-hoc manual code, nor did we make enough
use of this declarative alternative. This PR fixes that.

### Security Considerations

An advantage to the old ad-hoc manual style is that the enumeration of
all possible alternatives was textually close to the dispatch on the
alternative. This makes it easy to keep the two in sync. Thus, a
comparative disadvantage of this PR is their separation, leading to
maintenance hazards if one is updated but not the other. For example, if
the declarative form adds another option that the dispatch code does not
take into account, that other option might fall into the dispatch's
fall-through case. This may or may not be good, depending on whether the
fall through case is carefully chosen to also be appropriate for new
not-previously-recognized options.

### Scaling Considerations

none
### Documentation Considerations

none
### Testing Considerations

The text of the error messages for unrecognized options will likely be
different. But aside from that there should be no observable difference.
Since we do not consider a change to the text of an error message a
correctness concern, we consider this PR to effectively be a pure
refactor.

### Compatibility and Upgrade Considerations

Both before and after this PR, we generally reject unrecognized
environment options settings. This makes it difficult to grow existing
options with new settings that are ignored if seen by previous code.
This hinders plausible development patterns. This PR by itself does not
change that. But by centralizing the detect-and-complaint logic and
making it more declarative, perhaps we become better set up to address
this issue later.

Closes: #XXXX
Refs: #1710

## Description

#1710 enhanced `getEnvironmentOption`
with an optional third argument listing all the other allowed choices
aside from the default choice. Previously, we had only manual code to
detect and complain of unrecognized environment option values. #1710
provides a more declarative form, and reuses the
checking-and-complaining logic. However, following #1710 we did not
retire much of the previous ad-hoc manual code, nor did we make enough
use of this declarative alternative. This PR fixes that.

### Security Considerations

An advantage to the old ad-hoc manual style is that the enumeration of
all possible alternatives was textually close to the dispatch on the
alternative. This makes it easy to keep the two in sync. Thus, a
comparative disadvantage of this PR is their separation, leading to
maintenance hazards if one is updated but not the other. For example, if
the declarative form adds another option that the dispatch code does not
take into account, that other option might fall into the dispatch's
fall-through case. This may or may not be good, depending on whether the
fall through case is carefully chosen to also be appropriate for new
not-previously-recognized options.

### Scaling Considerations

none
### Documentation Considerations

none
### Testing Considerations

The text of the error messages for unrecognized options will likely be
different. But aside from that there should be no observable difference.
Since we do not consider a change to the text of an error message a
correctness concern, we consider this PR to effectively be a pure
refactor.

### Compatibility and Upgrade Considerations

Both before and after this PR, we generally reject unrecognized
environment options settings. This makes it difficult to grow existing
options with new settings that are ignored if seen by previous code.
This hinders plausible development patterns. This PR by itself does not
change that. But by centralizing the detect-and-complaint logic and
making it more declarative, perhaps we become better set up to address
this issue later.