Deduplicate cut outs on containers and fronts

Once a cut out has appeared on a page, it ought not to be repeated. We need to de-duplicate cut outs both across a container level (for templates that render a single container, e.g. tag pages) and across a front level (for Facia pages).

This 

![screen shot 2014-11-02 at 21 47 21](https://cloud.githubusercontent.com/assets/1001642/4877043/02227204-62db-11e4-988b-a2bbe4a56ad3.png)

becomes this

![screen shot 2014-11-02 at 21 47 28](https://cloud.githubusercontent.com/assets/1001642/4877045/10512fe6-62db-11e4-8dcb-57c472c8e03a.png)

And this

![screen shot 2014-11-02 at 21 47 58](https://cloud.githubusercontent.com/assets/1001642/4877048/1e2df0c2-62db-11e4-9efc-4e35965fedca.png)

becomes this

![screen shot 2014-11-02 at 21 48 13](https://cloud.githubusercontent.com/assets/1001642/4877050/2929d9aa-62db-11e4-9496-836af3520427.png)

This ended up being trickier than I hoped, due to the spaghetti of dependencies in our templates, and due to the lack of information at the Scala level about how things are rendered. This is due to our deciding early on that most of the rendering logic would be at the CSS level to help us move quickly, but if we don't know whether a cut out will be rendered, we can't de-duplicate it at the Scala level.

Because of this I've made card sizes a first class citizen in the Scala code. CSS classes are now derived from those objects. This also helped clean up the hacky code that was relying on those CSS classes to fix the display bug with Video.JS.

Card type information needed to be associated with the trail itself, so that I could pass over the structure of what items were above 'show more' and correct the cut out field if it had been seen previously. I ended up significantly refactoring (boo hiss!) the data structure so that instead of having the Trail passed directly to Facia templates we have an object that more directly represents what is actually being rendered, which made this significantly easier. I also think it's made a lot of the templates cleaner, as much more logic has been moved to where it properly belongs (IMO), in the code itself.

The result is a lot of code is changed again (sorry). One of the benefits is we're moving closer and closer to a data model of what is minimally needed to render Facia fronts - this will allow us in the future to refactor Facia Press so that it presses only that information, which will save us bandwidth (& thus money) and make Facia load more quickly (which will aid stability & dev productivity).

Note: I've not added tests to some of the more complicated logic in this yet as I expect some of it will be controversial. Will add tests if I get consent. 
Is this one of the 'benefits' of scalaz?!