CLI: all --eval <code> should evaluate

[StefanKarpinski]

Currently we only evaluate the last --eval <code> argument. This makes it impossible to build up a sequence of code to run via separate --eval arguments, which is often useful. Our current behavior is also at odds with Perl and Ruby which are generally considered to be good models for useful CLI behavior:

$ perl -e 'print("this\n");' -e 'print("that\n");'
this
that
$ ruby -e 'print("this\n");' -e 'print("that\n");'
this
that

In Python, the first occurrence of -c terminates option parsing, which we do not do, so following Python here would not make sense. A more conservative choice would be erroring on multiple --eval options, which would allow us to change the behavior in the future without breaking code.

[JeffBezanson]

For now should at least have an error for multiple occurrences (same deal for the -L option) to prevent dependence on the current strange behavior. I agree it would be good to eval all -e expressions, but implementing that is a bit difficult due to how options are stored and passed around.