Shim some scripts

Shimming is all good when it's included in the same file as the dependency, though this doesn't appear to be possible for shimming jquery in our case when the module is loaded outside of app_core:

> Do not mix CDN loading with shim config in a build. Example scenario: you load jQuery from the CDN but use the shim config to load something like the stock version of Backbone that depends on jQuery. When you do the build, be sure to inline jQuery in the built file and do not load it from the CDN. Otherwise, Backbone will be inlined in the built file and it will execute before the CDN-loaded jQuery will load. This is because the shim config just delays loading of the files until dependencies are loaded, but does not do any auto-wrapping of define. After a build, the dependencies are already inlined, the shim config cannot delay execution of the non-define()'d code until later. define()'d modules do work with CDN loaded code after a build because they properly wrap their source in define factory function that will not execute until dependencies are loaded. So the lesson: shim config is a stop-gap measure for non-modular code, legacy code. define()'d modules are better.

There is also the wrapTrue build option but this has limited effectiveness in my tests and not sure how much we want to rely on it:

> As of 2.1.11, shimmed dependencies can be wrapped in a define() wrapper to help when intermediate dependencies are AMD have dependencies of their own. The canonical example is a project using Backbone, which depends on jQuery and Underscore. Shimmed dependencies that want Backbone available immediately will not see it in a build, since AMD compatible versions of Backbone will not execute the define() function until dependencies are ready. By wrapping those shimmed dependencies, this can be avoided, but it could introduce other errors if those shimmed dependencies use the global scope in weird ways, so it is not the default behavior to wrap. More notes in http://requirejs.org/docs/api.html

So essentially, we can easily shim core modules. Not so easily handle others. For this reason I've wrapped nouislider in a define and removed it from bower.json. This is the only module we're including which causes these problems.
Is it maybe worth at least leaving a comment in here saying that we've modified this, and why? Or should it be moved out of here since it's been modified?