Addon runtime and buildtime config

[mehulkar]

Apps should automatically get a namespaced way to pass runtime and buildtime config that an addon can then access easily. Currently

1. each addon makes up its own rules about where to read config from the parent app
2. addons can supply default config to the app in config/environment.js (haven't tried this, not sure how it becomes accessible to the app).
3. runtime and buildtime config can be under different keys.

Proposal is to make the name of the package the key in both ember-cli-build.js and in config/environment.js.

[jelhan]

I think the v2 addon format should be taken into consideration. I hope the build-time macros will replace some of the run-time configuration. But I agree that there is still a need to standardize the rest.

I noticed how hart it is to get it right with the current primitives while refactoring the configuration interface of ember-cli-content-security-policy. Needed a few iterations until I landed on a solution that solved all problems. One problem I haven't thought of before: the configuration stored in ember-cli-build.js is only available in some build hooks. Finally landed with an addon specific configuration file config/content-security-policy.js.That seems to be the third established pattern beside config/environment.js and ember-cli-build.js.

Having three different locations for addon configuration doesn't feel like convention over configuration. And not having a naming convention for the keys used (config/environment.js and ember-cli-biild.js) or the filename (config/foo.js) doesn't help.

Not sure if the package name is a good convention. I know that's what most addons are currently doing. But:

1. The package name contains dashes in nearly all cases. Property names with dashes don't provide a good developer experience in JavaScript. I think that's the reason why some addons use a camelized version of it's package name.
2. Most package names are prefixed with ember. It doesn't help with readability if nearly all configuration keys start with the same term.

[mehulkar]

I'm reading the v2 addon format RFC and this would be covered under there. Although I originally was thinking that the best way is to have a static key, the macro system proposed in v2 format describes a different configure system that would achieve the same goal of making it easier to pass around config. https://github.com/emberjs/rfcs/blob/master/text/0507-embroider-v2-package-format.md#build-hooks

Going to close this in favor of (already merged) #507.