avoid term 'lvalue' in error messages about chapel

[mppf]

PR #15800 improves this situation by complaining about "const values" in many cases. However for a case like future variables/constants/assignValueExprError.chpl :

proc returnsIntByValue() { return 1; }  
returnsIntByValue() = 1;

the compiler will still report an lvalue error. It currently reports

assignValueExprError.chpl:2: error: illegal lvalue in assignment

@bradcray suggested that it could report

assignValueExprError.chpl:2: error: cannot assign to const expression

Arguably, we could use const expression in all of the error messages (instead of sometimes reporting const value as the compiler will do after PR #15800).

[lydia-duncan]

I wholeheartedly support moving away from "lvalue" in error messages

[bradcray]

I threw the "easy" tag on here because I think it is (modulo agreeing on what the new error messages should say... but lots of things would be better than what we have today).

[dmk42]

I agree with the concept for general users, though seeing the term lvalue in an error message saved me some work the other day, since it pinpointed exactly what was wrong. It will be difficult to come up with another term that works as well for that purpose.

[ben-albrecht]

I don't think this should have an [easy] label until we agree upon a replacement, which doesn't seem to be happening anytime soon.

[bradcray]

I think the person who owns this issue will need to sort through the error messages and propose alternatives based on the context (e.g., things like 'const', 'param', or 'read-only' may be appropriate depending on the context). I still assert that this is an easy task (including the proposal) but I'm trying to restrain myself from getting caught up into a label wrestling war.