Add a generate-all flag to emit all bindings

[srujzs]

In the case where a user wants to use an experimental API
that we don't include in package:web, it is useful to have the
generator emit bindings still so they can copy it over instead
of having to write all of it themselves. This also allows us to
find problems in our tools with newer bindings before they
become standard.

• Adds a generate-all flag to the tools and refactors code to
  incorporate it when determining whether to generate declarations.
• Cleans up argument passing so we're always using package:args.
• Adds a generate_all_and_analyze job to the Dart CI.

[srujzs]

This came up a couple of times, but most recently in #287.

[sigmundch]

LGTM, just a small suggestion below

[sigmundch]

I was trying to see if we could get away without making this static and without too much refactoring, and it appears that maybe it's possible?

Seems we use this property in:

• BCDItem subclasses's shouldGenerate getters: those however appear to be used within the context of a method that already checks for generateAll (isEventHandlerSupported and shouldGenerateInterface) so it may be safe to remove the use from these getters?
• the methods where generateAll is used also have access to a translator, so they can fetch the value through it (e.g. _shouldGenerateMember can read it from Translator.instance!.browserCompatibilityData.generateAll?

Would that work?

[srujzs]

Good idea! It took a little bit of refactoring, but making shouldGenerate a field allows this to work for the first bullet-point and the second bullet point works for translator.dart. isEventHandlerSupported doesn't need to check for generateAll since shouldGenerate handles that anyways.