Fix: Accept only option flags in CRYSTAL_OPTS for build commands

[beta-ziliani]

This is the reverted pr #11780 together with suggested fix #11921

Supersedes #11921 and #11780
Fixes #11164

[straight-shoota]

The use of CRYSTAL_OPTS with spec and eval is a bit troublesome. They only support a subset of compiler options and fail with CRYSTAL_OPTS=--warn-on-errors (because --warn-on-errors is no part of setup_simple_compiler_options (it probably should, though).
Anyways, the change is fine. This was broken before and it's still broken, so nothing changes.
But I think we should refactor the entire compiler command options parsing process. It's very obscure which compiler command actually accepts which options. And eventually, we should have a fixed set of build options that's allowed for CRYSTAL_OPTS and should work on any command. If the command doesn't use a build option, but it's allowed for CRYSTAL_OPTS, it should just be ignored.

[HertzDevil]

Ignoring unknown option flags at the OptionParser level could affect subsequent parsing, because they never consume an extra argument token, so those unsupported flags should be explicit no-ops; they could in turn be supported even for usual command-line arguments if we document the no-ops as such.

To me all the extra behavior suggests it could use a better name than just CRYSTAL_OPTS. I prefer the differences between command-line arguments and CRYSTAL_OPTS to be as minimal as possible.