Add support for explicit type arguments in new and call expressions (#7934)

* Add all option to babel-plugin-syntax-flow

The Flow parser has some conditional logic based on whether types should
be parsed or not, which is based on either (a) the @flow pragma in the
docblock of the file of (b) the `all` configuration, provided via
command line or .flowconfig.

This commit adds the ability to provide the `all` configuration to
Babel as well, via the syntax-flow plugin. This should be set to `true`
if the project uses all=true.

* Parse @flow pragma

The Flow parser has some conditional logic based on whether types should
be parsed or not, which is based on either (a) the @flow pragma in the
docblock of the file of (b) the `all` configuration, provided via
command line or .flowconfig.

This commit parses the @flow (or @noflow) pragma from the first comment
in the source file. Directives are allowed to appear before the comment.

* WIP: add tests for explicit type arguments

This commit includes tests which have unexpected output, but will change
to the expected output as later commits add parsing support for various
features.

* Parse type arguments in new expressions

* Parse type arguments in call expressions

* Parse optional call expressions with explicit type args

* Add explicit type arguments to babel-types

Flow calls these typeArguments instead of typeParameters, which clearly
separates formal/actual parameters, and mirrors the existing arguments
key.

The existing definitions to support TypeScript also included Flow's
TypeParameterInstantiation node type, which I've moved to the the new
field.

* Add support for explicit type arguments to babel-generator

* Add test for explicit type args to transform-flow-strip-types plugin

* Oops. Forgot to regenerate the babel-types README.

* Fix Flow parser shouldParseTypes() function

I was looking at `options.all`, but the correct property ws
`options.flowAll`. Oops!

* Remove typeapp_call from whitelist of expected failures

Now that Babylon parses this syntax extension, we can remove the
typeapp_call tests from the list of expected differences.

Note that I am using the `flowAll` option, mirroring the behavior of the
Flow tests, which assume types without requiring the `@flow` pragma.

* Use Babylon plugin options instead of parser options

* Parse optional call expressions type arguments unambiguously

packages/babel-plugin-syntax-flow/src/index.js

@@ -1,11 +1,15 @@
 import { declare } from "@babel/helper-plugin-utils";
 
-export default declare(api => {
+export default declare((api, options) => {
   api.assertVersion(7);
 
+  // When enabled and plugins includes flow, all files should be parsed as if
+  // the @flow pragma was provided.
+  const { all } = options;
+
   return {
     manipulateOptions(opts, parserOpts) {
-      parserOpts.plugins.push("flow");
+      parserOpts.plugins.push(["flow", { all }]);
     },
   };
 });