Follow-up from "Update documentation, warnings, and errors in gmx angle"

The following discussion from !5987 (merged) should be addressed:

• @mark.j.abraham started a discussion: (+1 comment)

  I realize this is pre-existing behaviour and recommend we do not change it in the release branch. But long after this code was written we adopted the principle that gmx should do what it was asked to do or give an informative reason why it can't. We think it is less annoying to a user to have to correct their command line (hopefully interactively) than to have to comb through a log to find that the output they requested was not written (or worse, that the output file they found was written by an earlier call to some tool and they never know there was an issue). We literally don't know which error the user made - forgetting to specify -ot or specifying -oh wrongly.

  So in main branch we should make this and similar cases a fatal error, like when the angle type mismatches. I suggest you close this thread with an issue targeted on some 2027 milestone to fix this :-)

Below are observed cases where the undesired behavior occurs:

• gmx angle:
  • line 274
  • line 285
• gmx cluster:
  • line 1063
• gmx dipoles:
  • line 1764
  • line 1769
  • line 1775
• gmx enemat:
  • line 679 gives warning that something is not implemented, but is not descriptive and I was not able to get it to throw in testing
  • line 296 throws error via a return, not a warning, but should be converted to gmx_fatal
• gmx rms:
  • line 338
  • line 350 never executes because it is associated with a hidden option.
  • line 364 will never execute because -s is required so can be removed
• gmx xpm2ps:
  • line 1613
  • line 1661