[pfff] Introduce a lexing hack to properly parse lambdas with typehints

Summary:
Lambdas are currently parsed in a pretty hacky way to avoid conflicts: any bracketed expression is allowed in the lambda parameters, which causes all sorts of problems when we attempt to introduce typehints (which can often look like expressions).

This introduces a lexing hack in `parsing_php_hacks.ml` to resolve these conflicts. Whenever we see a `==>` token (which can only be used for a lambda) we examine the preceding tokens to look for the parameters.
Once the parameters are identified, the open/closing parens are replaced with lambda-specific parens so the parser can easily identify them without context.

There are three main cases:

1) The last non-comment token was a variable. We don't need to do any processing for these, since they can't be typehinted and the parser can handle these fine
2) The last non-comment token was a closing paren. We match the preceding group of parenthesized tokens. At this point it can still be a typehint (for a function or tuple type). However, we can easily tell if a group of tokens represents the parameters or the return typehint by checking if:
  1) it's an empty pair of parens, or
  2) it contains a variable or variadic (`...`, `...$x`).
3) Otherwise, the preceding tokens must represent a typehint. We look for the last colon (not inside parens or brackets) and then look for a parenthesized group of arguments preceding that.

The typehint checking is a little sketchy - I didn't try to be overly accurate about it. It will never reject a valid typehint, but it might let invalid ones through. I think this is generally fine, as the real parser should be able to take care of that.

The grammar for lambda expressions is super clean now :D

Test Plan:
Ran over all files in www using this script:

{P17364735}

The resulting output is

```
/home/hansonw/www/flib/thrift/lib/fbcode/adsatlas/api/extif/atlas_api.thrift/atlas_api_types.php
/home/hansonw/www/flib/entity/query/core/filters/EntArgsBasedQueryFilter.php
/home/hansonw/www/flib/entity/core/mutator/__tests__/EntMutatorComponentProviderTestCase.php
/home/hansonw/www/flib/notifications/renderers/fql_common/__tests__/NotifFQLRepresentationTestCase.php
/home/hansonw/www/flib/third-party/php-openid/Auth/OpenID/TrustRoot.php
/home/hansonw/www/flib/third-party/php-openid/Auth/OpenID/Server.php
```

1, 5, 6 are legitimate syntax errors. 2 and 3 are caused by modifiers on variadics in the constructor, and 4 is caused by unpacking an array access (`...$x['abc']`) which is not parsed correctly since pfff lexes `...$x` as a `T_VARIABLE_VARIADIC`.

Also added a test `lambda_typehints.php`. Output of `pfff -dump_php` can be found at P17318696

Reviewers: pieter

Reviewed By: pieter

Subscribers: keito

Differential Revision: https://phabricator.fb.com/D1691785

Signature: t1:1691785:1416528091:2d0a27aaca9ea81976eb92191304fd40f9421ac3