Do not try to format null assert statuses

[domenic]

This was causing the completion callback that the harness added,

function (tests, harness_status, asserts_run) {
   this_obj.output_handler.show_results(tests, harness_status, asserts_run);
}

to throw an exception, which would prevent all other completion callbacks from running, which would prevent jsdom from ever collecting any results.

[domenic]

There may be a better fix, e.g. not adding classes to null asserts, but this unblocks me, and I'd like to get it fixed ASAP (perhaps with someone else's better fix) because failing to call completion callbacks seems like a pretty bad contract violation.

[stephenmcgruer]

This can be reproduced by running html/semantics/scripting-1/the-script-element/execution-timing/020.html (e.g. http://wpt.live/html/semantics/scripting-1/the-script-element/execution-timing/020.html); thanks to Domenic for pointing it out.

I'm going to use that test to try and write a unittest for this PR today.

[stephenmcgruer]

Ah ok, so what is happening here is that assert_any is not well supported by the new assert tracking code - it cannot handle nested asserts.

I think what we need to do instead is to have assert_any bypass the wrapper for asserts it calls (maybe?) so that they don't get recorded, but in the meantime a quick fix is to disable the wrapper for assert_any; I'll do that.