Move the Impressory scripts after the directive templates in templateFront

One of our users found that sometimes the directives were not rendering, and the console was full of failed calls to the server to fetch the templates.  This was an intermittent error.  It occurred to me that it may be a race condition between the scripts and the browser's html parsing.  As Angular.js was being initialised earlier in the page than the script elements that contain the templates for the directives, perhaps on occasion Angular.js would look for the template before the browser's html parsing had reached the script element containing it.

This commit moves the require.js invocation of Impressory to the last element in the page, so that the script elements containing the directive templates will already have been parsed by the browser before Angular.js is invoked.
Added /whoami

POSTing to /whoami returns a JSON representation of the user.
Render content sequences as a kind of content, rather than hardcoding support into the viewer

There's quite a lot of code in this little rationalisation of the content viewer.

- The viewer layout's left and right edges have moved into the partial template for ContentSequence
- The button for the chat side-pane is now on the content toolbar
- There is now an edit template for content sequence (rather than editing from the slide sorter)
- The old slide sorter is removed, as the edit functionality is supported by the edit template, and the slide-hopping functionality is in the view template for content sequence

Also fixed along the way
- FillHeight panes should resize themselves correctly when the header is minimised
- The edit content view is now a directive
- There is a route for retrieving the JSON of a single content entry (used by the edit view for content sequences)
- The edit item method for ContentSequences accepts JSON in the same format that it is sent to the client (i.e., with item.entries containing a JSON object for each content entry in the sequence, rather than just a string id)
- The tags in the content bar have been tweaked to inline from inline-block to avoid a problem where in Chrome they would flow onto multiple lines even if there's lots of room on the content bar (Chrome was defaulting the span for the tags to 180px wide).