Returntypehinting RFC

RFC'd by @morrisonlevi

PR'd for review + CI

https://wiki.php.net/rfc/returntypehinting
Can't think of other substantial reasons for now, aside from the main argument of consistency.

The _"What uses what?"_ argument also applies vice-versa:

    function ($value) use ($Beer) : Bar {

looks like the Bar belongs to the imported Beer somehow. — Neither of both hypothetical interpretations is functionally supported, and neither of them makes sense conceptually:

1. A return type can't use something. (That `use`, if any, is expressed within the return type declaration, elsewhere.)
2. Imported variables present input, not output, so they don't have or use a return type.

As a result, that's a zero-sum argument in either direction and not worth to pursue or count.

From an internal parser/compiler/AST but also user-space Tokenizer/Reflection perspective, I'd normally assume that things would be simpler and more happy if the discrete constructs of signature vs. imports were separated in a consistent way.

Also tried to brainstorm about potential future language grammar changes, but couldn't think of any that would favor one of both directions.  Obviously, the grammar question would not exist, if imported variables were noted within the parameters; e.g., by using a hypothetical special prefix (quickly made-up in spirit of I/O pipes, don't shoot me):

    function ($value, <$multiplier) : array

In any case, I don't think we should necessarily follow HHVM with regard to this grammar aspect; I may be mistaken, but I don't think HHVM invested a lot of time to discuss its grammar in much detail but rather focused on getting "a" grammar out of the door.

Lastly, I definitely would not want to see support for both syntaxes; that's not an option - before doing that, I'd rather swallow the inconsistency.