#1173 Move away from hardcoded amd module ids

Originally at 2015-04-10T20:51:22Z by Herbert Vojčík Amber packages are loaded as AMD modules, they specify their list of dependencies and those lists should be stable enough so they can be relied upon and will not be suddenly renamed by third-party (like the library author), rendering the package unloadable. Before .amd.json files and mechanism of generation of path mapping in config.js, this was a big issue which led to the decision to hardcode module ids in their define call, despite knowing this is not the preferred solution in AMD circles. Now, with having .amd.json files and coming up with other techniques easing rename-migration ("map" section with "forwarding pointers"), this is less of an issue and preferred method of not having an id hardcoded, but instead constructed by loader itself from path prefix and file name itself, is achievable. The plan is eventually move there with Amber. <bountysource-plugin> --- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/10881553-move-away-from-hardcoded-amd-module-ids?utm_campaign=plugin&utm_content=tracker%2F79201&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F79201&utm_medium=issues&utm_source=github). </bountysource-plugin>

Landed in d16a0d2.