Rephrase "assigning/binding to rvalue" errors to include context (#119)

[motiz88]

This replaces all "Assigning to rvalue" and "Binding rvalue" errors with more detailed variants based on the example in #119.

The implementation is the most straightforward one I could come up with - I add an optional context argument to checkLVal, toAssignable and toAssignableList, a simple string which is interpolated into the final error message (if any).

In some cases I made decisions that make the messages more informative in my view - e.g. making ArrayPattern pass through any parent context, so errors look like "invalid left-hand side in assignment expression" rather than "invalid left-hand side in array destructuring pattern".

Notes

1. The wording is of course not set in stone and I'll happily implement any suggested changes.
2. It's may be preferred aesthetically to move contextDescription leftwards in the methods' parameter lists, to avoid all those added undefineds. If there's a specific signature you'd like to see here - please let me know.

[codecov-io]

Current coverage is 94.46% (diff: 100%)

Merging #123 into master will increase coverage by 0.04%

@@             master       #123   diff @@
==========================================
  Files            19         19          
  Lines          3105       3110     +5   
  Methods         327        327          
  Messages          0          0          
  Branches        816        817     +1   
==========================================
+ Hits           2932       2938     +6   
  Misses           94         94          
+ Partials         79         78     -1   

Powered by Codecov. Last update 650e333...85b22d0

[hzoo]

I think it looks good overall? there's a merge conflict atm

traceur does: Invalid left-hand side expression in assignment: func() - dono if it's more helpful to add the left hand side in the error message?

What are the possible left hand values (Identifier/MemberExpression)? - maybe we can suggest that

[motiz88]

Working on that merge conflict now.

[motiz88]

FWIW, I'm personally not crazy about the idea of adding bits of code to error messages, for a number of reasons (though it's probably a matter of taste more than anything).

• We wouldn't always want to clutter the message with the full left-hand code (imagine the output for func ( /* lots of arguments and complex expressions here... */ ) = 5), so we might introduce formatting and abbreviating logic, which can be nontrivial and lead to bloat.
• There's already location information in the error object - my ideal workflow would be one where a tool / frontend just consumes and visualizes that (along with a clear, concise message), without babylon trying to hint at it separately via the error message.

[hzoo]

We wouldn't always want to clutter the message

fair enough