Reject incombatible flag combinations in to nuon

[sholderbach]

Description

Follow up to #12591

Ensure an error is shown.

.expect is fine here as the precondition of reaching each branch is
explicitly that this flag has been found. Only extra care has to be
taken when changing the flag name. But that is the general risk of this
stringly typed API.

User-Facing Changes

Ineffective combinations of flags will now return a ShellError::IncompatibleParameters instead of returning output for which the exact behavior was previously undefined.

[sholderbach]

Marking as draft for a second as with this mutual excusion scheme --raw becomes actually useless.

#8366 introduced it with the implicit precedence scheme for --tabs and --indent so you can override those optional named ones with a --raw. I think the implicit precedence rule for --tabs/--indent is a bad design. On the other hand there may be the assumption that you can override an otherwise configured to nuon call like that with --raw. If we go for maximum clarity on the mutually exclusive options --raw should be removed as it currently has no effect alone.

[fdncred]

Whatever we do here probably needs to be done for to json as well, so we can be consistent. I don't see any other --raw parameters on the to commands but seems like to xml and to yaml would be equally deserving of whatever is decided here.

In general, I think we should have a default (which I think is raw here maybe?), and then a way to override the default with the number of indents and then whether those indents are tabs or spaces.

[sholderbach]

The difference for to json is that there --raw does have an effect.
Our nu-json fork from hjson outputs with linebreaks and gratuitous whitespace, and the flag removed that (before #11900 switched to serde_json as a serializer in this case, by actually pulling out whitespace afterwards).
to json --indent 2 is the implied default value. So there all option could fully be mutually exclusive.

The one argument for keeping --raw here would be that you could more cheaply toggle between human or machine output in programmatic Nu code.

def my_func[--human-readable] {
  ls | first 3 | to nuon --indent 4 --raw=(not $human_readable)
}

At the same time for interactive use and general readability having these implicit overrides is less fortunate, if you don't start writing documentation sermons like in the description of #8366