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.
Updated Tasks Show View Logic

Updated the logic and initialization on the task show view to behave the
same as Profiles (to an extent).  There is now the ability to render the
view state (tags, task specific data, etc) and then edit that as well,
fetching all the data needed right there in the show view.  Eliminating
the need to do it again in the edit view.  Template files have yet to be
checked in, still working out bugs.
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
Fix up event view

- Show time in human readable format
- Link to the correct ical
- Fix broken html
Make the default state for tasks public

Tasks weren't displaying in the UI (correctly) because their
state was draft.  Since there's no UI yet to change the state
of a task, make the default state public and let the project
security settings control which tasks are viewable.
Experiment with moving tasks/events

Put tasks/events in the main column, and attachments on
the right.  This layout is not great, but better than
things in the sidebar.

I have an idea for how to make this MUCH much better
but not enough time to implement it before today's
demo.  So checking this in since it is an improvement to
the way it was.
Fixes Issue #36 Enhancement Request.

- Added back button to modal wizard.
- Restructured layout based on feedback.
- Attempted to replicate Location field appearing when you select any
  location, couldn't replicate.
Checking in the second section of Tags on TaskShow

This is a quick checkin for the tags so that I can make sure I don't
lose this code as I go to add on to it.  Simply iterating through tag
types and saving them as various names and that way I can access on the
front-end.
Checkin for task creation template.

This checkin contains some of the re-arrangements necessary for task
creation.
Merge sprint8 tasks with sprint8 layout

Resolve differences and test for demo.
Merge latest task madlibs and view

Merge branch 'sprint8-feature-task-show' into sprint8-merge
Clean up tasks

Make "show opportunity" actually go to the opportunity.

Don't use HTML paths to try to find a data element, this is
bound to fail when the HTML changes.

Create seperate class names for the task-list description
and the task-show description (they're seperate pages)
Add the description of the task

to the task show page.