optimize fail msg handling

[kellyredding]

No need to create all these fail msg strings if the assert passes. This moves the custom "what failed" message definition to a block. The block is only yielded to if the assertion fails.

This also reworks the processing of fail messages to not work in Procs but instead just take arbitrary string args and join them with new lines.

The added overhead of creating a block for every what failed message should be negated by removing the overhead of creating a proc for processing every fail message that we were already doing.

@jcredding ready for review. Not this has a few "breaking" changes:

• can't pass a block to the fail method (not sure why you even would?)
• can no longer pass a "what failed message" as a 3rd param (this was never part of the public API - just used internally)

[jcredding]

@kellyredding - Curiously, you might test how it performs if you have no procs and just use strings. It's kinda testing whether ruby is more efficient at making strings or procs.

[jcredding]

@kellyredding - This looks more efficient than the previous method of handling fail messages. If the procs are more efficient than the strings, I'm good with this :boom:

[kellyredding]

@jcredding thanks for the suggestion of testing with strings - I switched to creating string instead of procs. The procs seem to be more efficient.

With strings:

3115 results: all pass

(13.507749 seconds)

With procs:

3115 results: all pass

(11.885248 seconds)

I'm going to go with this proc approach.