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

scripts/tests/flow/flow_tests_whitelist.txt

@@ -37,11 +37,4 @@ numbers/underscored_float_whole.js
 numbers/underscored_hex.js
 numbers/underscored_number.js
 numbers/underscored_oct.js
-typeapp_call/function_call.js
-typeapp_call/function_call_optional.js
-typeapp_call/method_call.js
-typeapp_call/method_call_computed.js
-typeapp_call/method_call_optional2.js
-typeapp_call/new.js
-typeapp_call/new_noparens.js
 types/declare_class/proto.js

scripts/tests/flow/run_babylon_flow_tests.js

@@ -111,7 +111,7 @@ const options = {
   plugins: [
     "asyncGenerators",
     "dynamicImport",
-    "flow",
+    ["flow", { all: true }],
     "flowComments",
     "jsx",
     "objectRestSpread",