Improve error for wrong return type, allow promotion in return position

[WardBrian]

While working on #1340, I decided it would be good to separately improve the message for this case. This meant storing the return type when you're inside a function definition, which then also allowed us to clean up the edge case of promotion inside a return. This can be seen as a (much cleaner) alternative to the fix I implemented in #1335

Submission Checklist

• [x] Run unit tests
• Documentation
  • [x] If a user-facing facing change was made, the documentation PR is here:
  • [ ] OR, no user-facing changes were made

Release notes

Improved error message provided when the wrong return type is returned from a function. Return statements now follow the same type promotion rules as assignment and function argument passing. The typechecker now allows infinite loops (while (1) without an internal break) to be the end of a returning function. Previously, an (unreachable) return statement was needed following the loop.

Copyright and Licensing

By submitting this pull request, the copyright holder is agreeing to license the submitted work under the BSD 3-clause license (https://opensource.org/licenses/BSD-3-Clause)

[nhuurre]

Hard-coded infinite loops like while (1) which contain a return statement are now considered valid without needing to put a dummy return statement afterwards.

Loops don't need return statements in them to be considered endless. More correct statement is that previously a returning function had to end in either return or reject() but now a while (1) { .. } loop without breaks is also accepted as terminal statement.