Add assert.continueOnFailure and assert.notThrows

[thejoshwolfe]

This enables a test file with many small independent tests to continue despite some of the tests failing.

[thejoshwolfe]

This strategy has a disadvantage of no longer throwing an error from the site of the failure. This could possibly mean that debugging and stack traces are less convenient. (See also #1230.)

A somewhat decent remedy to that problem can be simply using better messages passed into the assert functions. I have an idea of how to do that with the typeCoercion.js paradigm, which I'll look into doing now, and make a PR soon.

[leobalter]

This is a bad design and an anti-pattern. I’m not willing to stress this much because you’ve been challenging every feedback with subjectivity and not technical answers and I’m out of energy for this during this busy week.

These assertions would solve a very specific problem while causing so many hazard through the other thousands of tests. It also pollutes the scope even more with names as ‘fail’ in an unnecessary alternative to tell something doesn’t fail. You’re considering a single case - the one that solves your problem - but I need to solve the rest of this project. Fitting the remaining project to this flawed api is 99% of the problem.

I’m trying my best to be pragmatic and not personal. Don’t get me wrong, but this api is not shipping.