require.js loads dependencies by name, where the name can either be a key in the require.js `paths` map, or a reference to a URL. For example, if a file declares a dependency on "jquery", require.js knows that the proper URL is `js/vendor/jquery.min.js`, because it says so in the require.js config. If a file declares a dependency on, for example, "js/models/course", require.js sees that that name is not in the `paths` map, and so it constructs the URL by prepending the `baseUrl` and appending `.js`.

However, in production we have an optimization where we use [django-pipeline](http://django-pipeline.readthedocs.org/) to rename static assets based on the md5 hash of their contents -- so while the JS module may be available at `/static/js/models/course.js` in development, in production the URL will look something like `/static/js/models/course.a74c902.js`, which require.js can't deal with effectively. (We do this so that we can set far-future expiration headers, and change the URLs only when file contents change.) To make this work, I've changed how we deploy static assets in production, so that instead of renaming files based on the hash of their contents, we're now including the git commit hash earlier in the URL, so the URL will instead look something like `/static/c8d3f09/js/models/course.js`. As long as we set the `baseUrl` to `/static/c8d3f09`, this scheme will work just fine, whether we're running in development or production.

Because this means creating new URLs for every static asset on every deploy, this is going to result in more cache misses. In the future, we might use the [require.js optimizer](http://requirejs.org/docs/optimization.html) to compile all the JS modules into one file, and serve that file with the md5 hash optimization -- which would neatly solve this issue and allow us to go back to our prior (current) optimization/cache-busting technique. This pull request is massive enough as it is, though, and I wanted to go for the simplest possible solution.