allow aborting if we have unsupported configurations

Good evening!
This is a feature request (AFAIKT there's no configuration option or duplicate issue for this).

In many cases where nightly rustfmt is applied by CI in public repositories, users will often run cargo fmt themselves directly or through their editor causing warnings arising from using the stable rustfmt where the nightly is required. E.g.:

$ cargo fmt
Warning: can't set `reorder_impl_items = true`, unstable features are only available in nightly channel.
Warning: can't set `overflow_delimited_expr = true`, unstable features are only available in nightly channel.
Warning: can't set `blank_lines_upper_bound = 2`, unstable features are only available in nightly channel.
Warning: can't set `inline_attribute_width = 80`, unstable features are only available in nightly channel.
Warning: can't set `comment_width = 110`, unstable features are only available in nightly channel.

The problem here is that cargo fmt will succeed regardless (and there is no way to avoid this). Succeeding here is strictly worse than not doing anything because it will reformat the entire file / project with the wrong settings (and it's not always clear to the user that this has happened).

(This is mostly a problem in projects that do not compile with nightly - and lack an override - but uses nightly for convenience tooling like rustfmt).

My thought is that there could maybe be a configuration for abort_on_unrecognised_options causing rustfmt to exit 1 where it normally would emit a warning.

No file, test, or entry point is named. Start by tracing how unsupported rustfmt configuration options are parsed and currently reported as warnings, then identify the configuration behavior and exit status that would constitute completion; add coverage for the requested abort-on-unsupported-options case.