Add better execution timing when using launchcmd

sub_test times program execution. However, this number is inaccurate for
launchers that use a queueing system such as qsub/pbs and slurm. This number is
going to be particularly bad for tests that spend a long time in the queue
(such as our performance tests that run concurrently and request specific
nodes.) This adds some functionality to chpl_launchcmd to time once the
queueing system reports that the program has actually started running and once
it's done and puts that time in a file that sub_test then reports.

This number still isn't going to be too accurate since we can't poll the
queueing system that often. An accurate way to accomplish this would be to have
the launchers support a way to wrap the executable with a timer, and have that
timer report the results. That's more work than I want to do right now,
although it's probably the right way if we start doing multi-locale performance
timing for whole programs.
Add check to make sure launchcmd is being used to be sure var is set
Report .dat filename when genGraphs fails.

This should make debugging corrupt .dat file content easier.
Merge pull request #960 from thomasvandoren/report-dat-filename-when-gen-graphs-fails

Report .dat filename when genGraphs fails.

This should make debugging corrupt .dat file content easier.

r: @ronawho
uniquify launchcmd_exec_time_file
Merge pull request #958 from ronawho/better-exectime-for-launchers

Add better execution timing when using launchcmd

[reviewed by @thomasvandoren]

sub_test times program execution. However, this number is inaccurate for
launchers that use a queueing system such as qsub/pbs and slurm. This number is
going to be particularly bad for tests that spend a long time in the queue
(such as our performance tests that run concurrently and request specific
nodes.) This adds some functionality to chpl_launchcmd to time once the
queueing system reports that the program has actually started running and once
it's done and puts that time in a file that sub_test then reports.

This number still isn't going to be too accurate since we can't poll the
queueing system that often. An accurate way to accomplish this would be to have
the launchers support a way to wrap the executable with a timer, and have that
timer report the results. That's more work than I want to do right now,
although it's probably the right way if we start doing multi-locale performance
timing for whole programs.

The number it reports seems to be ~1 second higher than the actual execution time.