Improve implementation of error detection in calls to baton binaries

[colin-nolan]

Errors are not detected very elegantly in https://github.com/wtsi-hgi/python-baton-wrapper/blob/master/baton/_baton_runner.py.

If an error occurs and baton can deal with it, baton spews unstructured error messages to stderr and then returns a structured error message on stdout. ATM, the implementation detects these errors at a higher level by examining the machine-readable stdout.

If baton cannot deal with an error it is assumed that it will spew error messages to stderr and leave stdout blank. Such cases are been handled here (although the case where baton dies without leaving anything on stderr was not!).

This implementation is clearly hacky: the two types of errror (baton handled and unhandled) were implemented independently without much thought beyond getting some kind of error detection in place! There is also no consideration of the exit code that baton returns.

This issue is related to discussions with Irina in 4b9bca4.

[colin-nolan]

Proposed by @irinaColgiu to always raise upon content written to stderr, regardless of exit code or what baton writes to stdout: 4b9bca4#commitcomment-16950536.

stdout is worth checking for useful structured error messages.