[FEAT] render-portal, replaces in-element for wormhole support

[runspired]

The in-element API provided by @rwjblue in #331 was insufficient to support ember-wormhole and flexi. I have not yet done work to see if this PR will fix flexi, but it does fix wormhole and I'm reasonably confident it at least gets us closer to supporting that library.

in-element deficiencies

• no support for renderInPlace
• no ability to move the DOM from one remote target to another remote target or from a remote target to in-place.

naming

The wormhole concept has often been referred to as a "portal" or "portal-ing" in other frameworks and in talks. I'm also particularly partial to the game Portal.

[runspired]

I probably am missing things here, but I didn't know enough to know what all should be here.

[runspired]

Tests are passing locally, on sauce labs, and on travis, but some vscode tslint build thing is erring out and kicking it a few times didn't help.

[chadhietala]

@runspired If you go to typescript@2.0.0 instead of typescript@next it will fix the issues.

[runspired]

@chadhietala thanks!

[runspired]

@chancancode I can rebase this, but I'm pretty sure what I spiked here needs refinement. I'd love a review, and pointers in the right direction, so we can make sure that wormhole et al. using this technique have a good story in Glimmer.

[rwjblue]

@runspired - I think we should probably close this specific PR (its out of date, and will be hard to bring it back into alignment with current master without just redoing the work), but we should make an issue that documents the shortfalls around in-element so that we can collectively decide on the right way forward...

[tomdale]

Closing this as it seems to have gone stale. We're definitely still open to improving {{in-element}} to support more use cases, but this part of the code has changed quite a bit recently.