Added logic and HTML to the Task Show page.

- Also added an ajax loader transition paradigm, and implemented it, with the
  assets, to the project show and task show view transitions.  This
  transition takes place during the page transfer from one to the other.
  Ideally always placed in the router, and abstracted using the helper
  methods within the utility file.
Updated class and styles to follow paradigm.

Updated the class and styles for the ui-loader and ajax-loader to follow
our paradigm, and cleaned up the CSS file a bit.
Cleanup.

- Removed ajax loader for paradigm incoming in next commit.
- Added a comment to the top of task_show_controller regarding what I
  will be doing with it.
- Removed uneeded ajax spinner styles.
- Fixed whitespace.
Cleanup of ajax-spinner styles mentioned in previous commit.
Added new paradigm for Ajax Spinner, details below

There is now a base_view class that every RENDER ONLY child view should
extend off.  This base_class will automatically render the view once it
is ready to do so.  In this case, once it has set the ajax spinner and
attached it to the $el of the child class.  The child class then has its
render method called in which it flushes the DOM and adds new content to
its $el.

Definition of render only:
- It only renders, and that's it.
- NOTE: We have been adding more logic than is needed into the views
  themselves, and with this paradigm I hope to slowly get us back to
  using the controller more.  This is just the first step in bringing as
  much generic functionality as we can to the base_view class.

This means we no longer need to do this:

var viewName = new ViewName({
  el: "#someEl",
  model: someModel
  // ...
});
this.viewName.render();

We can simply do this:

var viewName = new ViewName({
  el: "#someEl",
  model: someModel
  // ...
});

And it will automatically know to initialize logic within the base class
with a reference to the view you call new on, and then render the
immediate child view of the base class (current instance initialized).

Based on analysis of our application, there is no situation in which we
initialize a view class but don't render it right there.  Sometimes
there is logic within the view if it is large, and thereby making it NOT
a -render only view-, in which the render method is the second, third,
or fourth method called within said view.  That class for now would not
be a good one to extend the base_view class on, as I mentioned above it
has to be a render only view class.  But eventially I'd like to check
for that and/or pass in a param to the constructor that allows the
parent class to know how and when to render its child view.
Added Production methods to the Gruntfile.

I added a production compile method to the grunt file, and the deps for
it in the package.json, tested, and built our project and stored it in
/assets/js/prod/midas.js.  We can change that directory we house this
in, but for now that seems fine.

To run this command simply open terminal, do an npm install, and
preferably npm install grunt-contrib-requirejs --save-dev, then type
"grunt requirejs" to execute the requirejs grunt command, and you will
see the app compiling.
Get requirejs to work in production.

This was a pretty hairy ugly undertaking.  Our requirejs
app was really not set up for use in dual-mode development
and production.  I've hacked the app to look more like a
well-defined require module.

I've then modified layout.ejs to check what environment
sails is running in (development or production)
and render to the page the correct <script> html.

When you lift sails, it does NOT generate the production
javascript... instead you need to do:

	grunt requirejs
	sails lift --prod

This will run the server in production mode with a single
javascript file (other than jquery).

There's still more work to be done here -- like figuring
out how to include jQuery in the configuration rather than
hacking it in as a <script> tag, but this seems to run
well locally.  The other thing would be to compile
the production js on sails lift (And also inspect what
sails is really doing during production to minimize
cpu and memory resources hogged by grunt)

Still need to test it on the remote demo server.
Remove debugging commented out script tag
Merge pull request #28 from Innovation-Toolkit/sprint8-feature-grunt

Merge grunt changes to use a single file in production