Prevent running babel twice.
We currently transpile the output of all addon's `addon/` trees twice. Once inside the addon's `treeForAddon` step (this one excludes module transpilation by adding `es6.modules` to babel's blacklist) and the second time in [lib/broccoli/ember-app.js](https://github.com/ember-cli/ember-cli/blob/2df251ce018fd12570bdce72c167ff14a427fa74/lib/broccoli/ember-app.js#L929).
This was originally done because we didn't require that addon's include their own preprocessors for JS (mostly due to performance reasons IIRC). In the time since that decision was made, we have swapped from a few different systems `es6-module-transpiler` -> `esperanto` -> `babel`. Now that our module transpilation step is using the same thing as we recommend addon's use (`ember-cli-babel`) what we are doing seems pretty whacky.
This PR removes the double processing of addon's `addon/` files through babel, and includes a deprecation message for the scenario that originally prompted the second pass (where an addon didn't include a module transpiling preprocessor).
- [x] Confirm that we have tests that already confirm this is working properly (I believe that our existing nested addon tests cover these changes, but I'd like to confirm).
- [ ] Consider / discuss backporting the deprecation message for addons that do not have a transpiler and are relying on the global processing step.
- [X] Add helpful error if an addon overrides `this.options.babel.compileModules`
- [X] Implement logic to avoid deprecation being added in babel/ember-cli-babel#105.
- [X] Split out `findAddonByName` into a utility method to be shared
- [ ] r?
Addresses parts of #5015