Stop performance testing if OPTIMIZED=1 build failed

* If the compiler OPTIMIZED=1 build fails, turn off compiler perf testing.
* If the runtime OPTIMIZED=1 build fails and it is a performance test run, it
  is a fatal error, so send the failure message and exit.
* Added the ability to exit on a fatal error back to mysystem after it was
  accidentally removed in a previous commit.

Tested by doing: nightly -debug -performance -notest
with and without things to warn about added to the compiler and runtime.
Merge pull request #264 from daviditen/nightlyPerf

Stop performance testing if OPTIMIZED=1 build failed

* If the compiler OPTIMIZED=1 build fails, turn off compiler perf testing.
* If the runtime OPTIMIZED=1 build fails and it is a performance test run, it is a fatal error, so send the failure      
  message and exit.
* Added the ability to exit on a fatal error back to mysystem after it was accidentally removed in a
  previous commit.

Tested by doing: nightly -debug -performance -notest
with and without things to warn about added to the compiler and runtime.
[reviewed by gbtitus]
Fixed some regressions from last nightly testing
Merge pull request #273 from vasslitvinov/fixup-tests-for-coercion-wrapper-elimination

Fixed some regressions from last nightly testing.

.good changes in the robustness suite are due to improved fork counts, possibly due to coercion wrapper elimination. I did not investigate.

I added a missing .good file.

For the rest:


functions/vass/setter-passed-to-another-fun.bad

=> I verified that the new contents of .bad are legitimate


types/enum/sungeun/cast_enum_weird_4.bad

=> This might not be related to my coercion-wrapper commit.
At any rate, the updated line number makes more sense
than the one that was there before.


types/records/const-checking/scenario-1-array-of-record-with-const-fld.bad
types/records/const-checking/scenario-2-init-array-of-rec-with-const-fld.bad
types/records/const-checking/scenario-3-assoc-dom-of-record-with-const-fld.bad
types/records/const-checking/todo-linenumber-in-array-assignment-error.future
types/records/const-checking/todo-linenumber-in-array-assignment-error.bad

=> The new line number reported by the compiler is not better than the old one.
Neither is perfect; passing --print-callstack-on-error gives the desired info.
The following future requests fixing this:
  todo-linenumber-in-array-assignment-error.bad