== pushFailure ==

This was setting `actual: null` and, left expected unset/undefined.
In HtmlReporter this idom was recognised to mean "don't show values",
based on hasOwn for `expected`. This worked because QUnit.log() passes
the internal assert result object as-is.

In TAP output, this was not skipped because Test.js#logAssertion
copies the object for the testEnd.errors array, and in doing so forges
an `expected` property to exist no matter what, thus with an implied
value of undefined. The hasOwn checks in TapReporter thus always
evaluate to true.

This meant TAP output for pushFailure() calls not only showed
redundant actual/expected entries, but actively created confusion
by setting them to different values, drawing attention to a supposed
difference that has no meaning

> actual: null
> expected: undefined

Fix by changing pushFailure to omit both actual and expected,
and change the condition in both reporters to skip rendering of values
based on both being strictly equal to `undefined`, instead of based
on `hasOwn('expected')`.

== onUncaughtException / `QUnit.on('error')` ==

For uncaught errors, we already omitted both actual and undefined,
the HtmlReporter thus already skipped them (for the reason above),
but in TAP output they showed, for the same reason as above as:

> actual: undefined
> expected: undefined

Which, while not as actively confusing, is at least redundant.
This is naturally fixed by the same change, which now omits this.