Refactor Value into command and expression values

[byorgey]

Overall I'm not happy with the way we handle VResult. It is a fertile source of bugs (#977 , #858, #327, #328) and will probably continue to be so because of some subtle invariants. It's necessary internally in order to pass along intermediate results that also carry an environment of bound names, but there are also many places where we don't expect to see it and don't want to have to worry about dealing with it. A few options for improving the situation that come to mind:

1. Remove VResult from Value, and create a wrapper type for "values with environment" (EValue?) which can be either a Value or a VResult, and carefully decide which instances of the Value type should change to EValue.
2. Add a type parameter to Value that indicates whether it is allowed to contain VResult or not.

Originally posted by @byorgey in #977 (comment)

Note that the distinction is precisely between values which result from evaluating an expression (which can never be a VResult) and values which result from executing a command (which can be).

[byorgey]

Note that the idea with #1087 is that we won't need VResult at all any more.