Move loader.js to be included as an addon.

[rwjblue]

This allows us to:

• Remove another bower dependency
• Ensure that ember-cli is properly paired with the loader.js version
• Remove reexporter code, since we now know for certain what loader.js we have.

Requires ember-cli/loader.js#64.

[rwjblue]

ember-cli/loader.js#64 was released as v4.0.0, rebasing this PR to include it.

[homu]

☔ The latest upstream changes (presumably #5367) made this pull request unmergeable. Please resolve the merge conflicts.

[nathanhammond]

I would prefer that the prepend check for this to be special-cased. That way in an ideal scenario it's:

• loader
• bunch of modules
• one invocation to unravel the world

That makes the way I'm thinking about service workers a lot easier.

Note: I don't want to let perfect be the enemy of good, if we're comfortable going back and adding this when necessary, let's ship this as is. (Pretty sure that would be backwards compatible too.)

[rwjblue]

@nathanhammond and I discussed this at length in #dev-ember-cli. The current plan of attack is to:

1. Ensure that app.import('adsfaf', { prepend: true }); maintains the correct order (currently the last thing to be prepended is first, which is a bit of a )
2. Leave loader.js as a user defined addon. This allows other addons that need to prepend (but still depend on the loader) to declare after: 'loader.js' in and they would be loaded at the correct time after the loader.
3. Add after: ['loader.js'] to default addon blueprint.

I am going to continue this PR and try to get it in a mergeable state (there are a couple addon tests failing ATM), and then follow this PR up with points 1 through 3 from above as a separate PR (that either @nathanhammond or I will work on tonight/tomorrow).

[stefanpenner]

👍