Tell hhbbc about enum type hints

Summary: It assumed they were type object, but they're not.

Reviewed By: @swtaarrs, @elgenie

Differential Revision: D1596140
Fix more hhbbc issues with enums

Summary: Name-only resolutions weren't handled in the last diff.

Reviewed By: @markw65

Differential Revision: D1596483
reflection support for first-class enums: enum_exists [1/2]

Summary: * function enum_exists : similar to {trait|interface}_exists
 * ReflectionClass::isInstantiable now returns false for enums

Reviewed By: @jdelong

Differential Revision: D1589055

Conflicts:
	hphp/runtime/ext/std/ext_std_classobj.cpp
make first class enums non-extendable by regular classes

Summary: ... and therefore ReflectionClass::isFinal becomes true for
 ReflectionClass of enums.

Reviewed By: @jdelong

Differential Revision: D1589531
Fix unsafeexpr parsing.

Summary: The lexeme_start of the unsafeexpr token used to be misplaced. This
caused parse errors whenever the parser invoked L.back, because we would only
backtrack over the '*/' sub-token.

Reviewed By: @jwatzman

Differential Revision: D1557591
ensure classes in strict mode have members fully known

Summary: Strict mode should declare fully known types.

Reviewed By: @pikatchu

Differential Revision: D1230872

Conflicts:
	hphp/hack/src/utils/errors.ml
Better errors on runtime generics.

Summary: Closes https://github.com/facebook/hhvm/issues/3711

Reviewed By: @jwatzman

Differential Revision: D1565849

Conflicts:
	hphp/hack/src/utils/errors.ml
	hphp/hack/src/utils/errors.mli
Check exprs with short-circuit operators correctly

Reviewed By: @jwatzman, @elgenie

Differential Revision: D1567624
Fix handling of exit() in nast_terminality

Reviewed By: @elgenie

Differential Revision: D1590318
Fix subtyping for enum types with constraints.

Summary: Move the code that handles that case to the end, so we can take
advantage of the other cases that handle the peeling off of Toption,
etc.

Reviewed By: @elgenie

Differential Revision: D1596826

Conflicts:
	hphp/hack/src/typing/typing_subtype.ml
Fix parsing of postfix operators.

Summary: Based on what I understand of the parser's reduce code, this should be the
right way to parse things...

It might look like expr_postfix_unary is completely disregarding precedence,
but that's because the functions calling it handle precedence already.

In `$a->b++`, reduce() 'shifts' `$a->b` onto the stack, finds out that `++` has
lower precedence than `->`, then returns. So expr_postfix_unary gets called with e1
set to `$a->b`.

In `$a && $b++`, when parsing $b, reduce() sees that `++` has higher precedence
than `&&` and so creates `$b++`.

Finally, the precedence of a postfix operator should not affect the remainder
of the parse. I.e. we should parse `$a && $b++ === $c` as `$a && ($b++ === $c)`
rather than `($a && $b++) === $c` -- even though `++` has higher precedence
than both `&&` and `===`, we decide to shift `===` based on the relative
precedence of `&&` and `===`, and `++` does not come into the picture.

Reviewed By: @pikatchu

Differential Revision: D1598832