Allow to configure flatc diagnostics (was: disable lowercase snakecase warning for fields)

[hasselmm]

Problem

flatc has two knobs for diagnostics, and they are binary.
--no-warnings silences all of them, --warnings-as-errors promotes all
of them. There is nothing in between.

That leaves any project that has consciously decided not to follow one
particular recommendation with two bad options. The recurring case is the
field naming warning from #6005: schemas that mirror or are generated from
an existing code base cannot rename their fields without breaking the very
thing they exist to describe. Such a project can either

• accept the warning, and have it repeat for every field on every build
  until real diagnostics are invisible in the noise, or
• pass --no-warnings, and give up every other diagnostic flatc offers.

The second is especially painful in CI, where --warnings-as-errors is
exactly what you want for the warnings you have not opted out of — and
it is unreachable today, because opting out of one warning means opting
out of all of them.

This has now come up in #6032, #7111, #8612 and #9243.

What this changes

Both options take an optional, comma separated list of warning keys:

# inhibit one warning, keep the rest
flatc --cpp --no-warnings=strict-field-names schema.fbs

# ... and still fail the build on anything that is left
flatc --cpp --no-warnings=strict-field-names --warnings-as-errors schema.fbs

Key	Warning
strict-field-names	a field name is not lowercase snake_case
implied-attribute	an attribute is already implied by another one
repeated-attribute	an attribute is given more than once
unsigned-bit-flags	a bit_flags enum has a signed underlying type
all	all of the above

A warning inhibited by --no-warnings is never reported and therefore
never becomes an error, which is the behaviour --no-warnings already has
today with respect to --warnings-as-errors.

What this does not change

• No default behaviour change. Every warning stays on by default.
• No new command line option. Both spellings already exist.
• No existing command line is affected. Without an argument both
  options behave exactly as before. Only the = form takes a list, so
  flatc --no-warnings schema.fbs still treats schema.fbs as input.
• The warnings themselves are untouched — same conditions, same
  wording, same locations.

Notes for review

• Unknown keys are a hard error rather than being ignored. A silently
  accepted typo would leave the warning enabled and make the option
  useless in CI, which is the main place it is wanted.
• IDLOptions::no_warnings becomes disabled_warnings and
  warnings_as_errors becomes a WarningFlags bit set. Both members are
  renamed rather than retyped in place, so downstream code assigning a
  bool fails to compile instead of silently meaning "one warning".
• IDLOptions::Warning follows the Language/lang_to_generate pattern
  already in IDLOptions: an unscoped k-prefixed enum with a fixed
  underlying type, stored in an integer. No casts, no operator overloads.
• Adding a future warning is one enumerator plus one row in
  warning_options; the parser and the --help text share that table.
• --warnings-as-errors was not documented in flatc.md at all. It is
  now.

Tested with FLATBUFFERS_STRICT_MODE=ON; flattests passes at each
commit, and the new cases cover per-key inhibition, per-key promotion, key
combination, and the interaction between the two options.

Closes #9243.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[hasselmm]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

CLA should be signed.