Change resize listener destruction ordering

[tivac]

Fixes #4752

This swaps the order on the destruction of the resize listening <iframe> that is created whenever you use bind:width, bind:height, etc.

The <iframe> is now destroyed before the element being bound to, and the resize event listener is now removed from the <iframe> before it is detached from the DOM. This works around an issue in older versions of WebKit where once the <iframe> is detached its .contentWindow property is gone and the unsubscription throws errors.

Before submitting the PR, please make sure you do the following

• It's really useful if your PR relates to an outstanding issue, so please reference it in your PR, or create an explanatory one for discussion. In many cases features are absent for a reason.
• This message body should clearly illustrate what problems it solves. If there are related issues, remember to reference them.
• Ideally, include a test that fails without this PR but passes with it. PRs will only be merged once they pass CI. (Remember to npm run lint!)

Tests

• Run the tests tests with npm test or yarn test

NOTE

I ran the tests, but since I'm on windows the results were drowned out in \r\n vs \n noise. Is there a doc somewhere about the right way to fix that for this repo?

[Conduitry]

For the Windows thing, there's a note in the readme in this section about how to clone the repo in Windows with LF instead of CR LF so that various tests pass.

[tivac]

Thanks @Conduitry, I knew I'd seen that somewhere.

[tivac]

This isn't actually a complete fix, it only solves for the case where an element is destroyed. I'll continue investigating on how to support the destruction of an entire component.

[tivac]

Added a tremendous kludge that fixes the simple version of the issue by having component destroy methods add themselves before their immediate parent using Array.prototype.splice(-1, 0, ...) when adding to block.chunks.destroy. I... don't feel good about this, but all the tests pass and it works fine in my application.

Is there a better way for the InlineComponentWrapper renderer to know "hey I have a parent element and I want to make sure my destroy runs before theirs"? I looked into block.wrappers a bit but I don't think that's necessarily what I want either.

Another option I kicked around for a bit is adding a new chunk to block.chunks, obviously I have no idea what to call it but the idea would be to separate components & elements that need destroying so they could be managed separately. Don't love the extra size that'll add to the output though.

[tivac]

Bah, doesn't account for deeply-nested components though. There's another intermediate component in the real app that is still deleting its DOM before its components.

[tivac]

Gonna close this for now, I don't think this is the right approach. I've got a question out to the most recent author of this code to try and vet a different approach that also solves my issue w/o needing to deeply change the way destroy works.