Don't swallow deprecations and warnings when there is no test context

[kategengler]

Allow them to proceed to the next handler.

Observed this behavior in an application: Deprecations thrown outside of a running test are swallowed by this handler. For example, when running tests on ember-resolver, no @ember/string deprecations are thrown, even though deprecate is called.

I am not sure if this was intentional, but it makes it hard to test that a deprecation isn't thrown by a package.

How can this be tested in the test suite here?

I attempted various ways to test this in the test suite but was unsuccessful. I attempted to add my own registerDeprecationHandler to confirm it was called by the one in setup-context, but I was not able to register my handler in advance of the handler in setup-context, which means mine was always called before the one in setup-context. My attempted test never failed. Is there a good way to inspect the console output? I am mostly concerned with the default logging handler.

This change can be confirmed in a project (as I have in ember-resolver) and also there are a few tests in the suite that trigger deprecations without a context. Before this change, they do not log to the console, after, they do.

[MelSumner]

I don't know (immediately) how to improve what you have here, but I do think that "Before this change, they do not log to the console, after, they do." is enough for a start.