Bookmarks

This implements bookmark support throughout the current gaffer applications. It turned out to be a bit more complicated than I'd thought. The Bookmarks class provides the basic API for managing bookmarks, and instances of this are acquired per application/pathtype/category - this allows independent sets of bookmarks for different things. Each category of bookmarks also as a fallthrough to a category-less set, this makes it easy to manage bookmarks that make sense for all sorts of files and then overlay bookmarks on top for specific sorts of files. Bookmarks can be created in config files, and also by users through the UI. Bookmarks can also be dynamic callables which return different values depending on the context they're viewed in - this allowed per-script bookmarks to be implemented for the main gui app but I imagine could be useful for our pipeline tools also (automatically making bookmarks relative to the current shot in the ui perhaps).

There are a few points worth noting when reviewing :

- I added an argument to a protected method in e9aaeeb. I really doubt that we're relying on it but wanted to point it out so we can check. There are some comments in there about how the mechanism we're using had problems anyway - we could take the time to address those now if you like, although to be honest I'd rather be done with this one since it turned into a much bigger task than I expected already...

- I hadn't anticipated the burden on the clients of PathChooserDialogue to be the ones to have to find bookmarks, but in the end I think it's the right thing to do. The PathChooserDialogue is a low level UI item which doesn't know about applications or anything else - it's only the higher level items that know about nodes/apps so it seems reasonable that they should be the ones to acquire the bookmarks.

- Because bookmarks are a per-application thing, they're acquired by finding the ApplicationRoot. The op app was basically ignoring its root entirely, so now it has to make use of it to support bookmarks, by storing its op on a node in a script on the root. This had knock on effects into OpDialogue, but that still supports the old mode of usage that I expect we're relying on in Jabuka.

- I'm not happy about the PathChooserDialogue clients being the ones which apply the default bookmark when the initial path is empty - I originally implemented it so that the PathChooser would do it itself. The problem with this was that context sensitive bookmarks couldn't be evaluated properly until the dialogue was parented to the ScriptWindow and on-screen. Changing the path at this point caused flickering in the UI that I couldn't find a way around. Then I realised that most of the clients had some sort of default-path logic already, so it didn't seem that bad to replace it with something better and more configurable.