Allow errors and failures to be strings

[jml]

TestResult.addError and TestResult.addFailure should both be able to handle strings as well as failures and exception tuples.

[jml]

[13:23]  <exarkun> what
[13:24]  <exarkun> strings are _crap_
[13:24]  <exarkun> errors and failures cannot be strings
[13:24]  <radix> strings are really bad.
[13:24]  <exarkun> kenaan: reject reject reject reject
[13:25]  <radix> maybe addError and addFailure should take IError or IFailure providers.
[13:25]  <radix> or adaptables.
[13:25]  <jml> radix: *stab*
[13:25]  <exarkun> woo stabbing
[13:25]  <radix> jml: seriously, strings suck.
[13:25]  <radix> jml: don't do strings.
[13:26]  <jml> radix: reason, not dogma.
[13:26]  <exarkun> jml: strings are opaque.
[13:26]  <radix> jml: exarkun has good reasons
[13:26]  <exarkun> jml: programs should operate on data structures.
[13:26]  <radix> jml: he has tried doing things with addError and addFailure
[13:26]  <exarkun> jml: a string is what you put onto a terminal or into a file descriptor
[13:26]  <jml> I am getting these errors and failures out of a file descriptor
[13:26]  <jml> from javascript
[13:26]  <radix> ahh, subprocess!
[13:26]  <radix> or that
[13:26]  <exarkun> jml: yes, you get strings out of file descriptors too
[13:26]  <exarkun> jml: and then you turn them into data structures
[13:27]  <exarkun> jml: before you leave your protocol-level code
[13:27]  <jml> exarkun: fair enough.
[13:27]  <radix> jml: it sounds like you should be getting something out of that file descriptor and then building a better data structure out of it
[13:27]  <exarkun> once they are real data structures, they can get to the rest of your app
[13:27]  <radix> jml: now, after this really useful reason, I will make one point
[13:27]  * jml rejects the ticket and files something against subunit
[13:27]  <jml> radix: oh?
[13:27]  <radix> jml: reason: this dogma prevents lameness!