Add compatibility for embroider

[simonihmig]

Fixes #107

Follows the suggestions laid out in https://github.com/embroider-build/embroider/blob/master/packages/compat/src/compat-adapters/ember-window-mock.ts:

• there is now only the default export of the (mocked or original) window for the base module: import window from 'ember-window-mock';
• all mocking code is part of ember-window-mock/test-support, including the setup function: import { setupWindowMock } from 'ember-window-mock/test-support';.
  This is a breaking change
• the ember-window-mock module has some Proxy related code, so you can turn on and off the mocking behavior at runtime. Which means that import window from 'ember-window-mock'; gives you now a Proxy-wrapped window object even outside tests (that's new!), which however passes everything through to the original window unless setupWindowMock() is called. So apart from bugs, this should not make a difference, unless you are developing on IE11 😱
• In a production build however all of this Proxy code is stripped away, and you get the plain window global directly.

This also adds an Embroider test scenario, which however was passing even without the refactorings above, as the build included all the mocking code the tests expect. Now mocking code is not included anymore outside of tests, which I checked manually, but which we don't have any kind of test coverage for.

@ef4 in case you have a minute left, a quick review would be highly appreciated! 🙂
Hope this is reasonable so far and follows the (module) semantics that embroider expects!

/cc @kiwiupover

[rwjblue]

@simonihmig - Sorry for the late comment, I'm curious if you think this should be a stack instead of always resetting to null?

Specifically, should we reset to null or to whatever the value was before? What happens if you do:

module('foo', function(hooks) {
  setWindowMock(hooks);

  module('nested thing', function(hooks) {
    setWindowMock(hooks);
  });

  test('something that requires the window mock', function() {
    // ...snip...
  });
});

[rwjblue]

It is also vaguely weird that it would reset with null. I would think that you would want to call _setCurrentHandler() which would reset to defaultHandler (AFAICT calling with null will make any window access fail).

[simonihmig]

@rwjblue thanks for the review and the suggestions, I think they make totally sense! Especially that null thing was stupid, apparently I thought this would reset to defaultHandler, which you are right it does not. I should add some better test coverage, for what state setupWindowMock leaves behind afterwards, especially for that nested usage...

[alexlafroscia]

For the record, as of 0.7.1 it no longer resets to null; it now returns to the default handler after each test.