Experiment: alternative function result types inference

[quasilyte]

To make function result types inference more predictable and controllable, we'll try to restrict it.

New function result type inference rules:

• If @return annotation exists, use that.
• Otherwise use return type hint.
• If neither present, infer actually returned types.

// @return is present, f1() -> int[]
/** @return int[] */
function f1(): array { ... }

// type hint is present, f2() -> mixed[]
function f2(): array { ... }

// type info is infered from actual results, f3() => int[]
function f3() { return [1, 2]; }

If we've used @return or a type hint, we need to perform a typecheckReturn
and verify that actually returned values do not contradict stated types.

Instead of doing a full value (and types) analysis for typecheckReturn, it's
proposed to perform a set of checks that detect only critical issues.

This set can be extended as we adopt this approach. At some point,
we may switch to a full types analysis and handle it as PHP would.

Examples of the critical issues we should report in typecheckReturn:

• Array types mismatch
  • @return array, but returned non-array
  • @return !array, but returned array
• Primitive/scalar types returned in place of object
  • @return object-type, but returned scalar type
  • @return scalar-type, but returned object type

Later, we may add checks for nullability.

It's also possible to check interface-returned types and whether
one class may be returned in place of another; see Covariance and Contravariance.

But since that's more complicated and we need to start somewhere and prepare the foundation,
let's focus on the simple things first and test it on the real projects.

Note: we should be ready to revert our changes in case this experiment is proven to be a failure.

[i582]

I consider the experiment to be successful.
Further type checks will be tracked in #1123.