Improved version numbering scheme

We always intended to use the semantic versioning scheme as defined at http://semver.org. However, in practice, we've kept the major version at 0 to indicate that we haven't yet fully locked down compatibility on anything, and we've compiled and installed all dependent tools separately for each and every version of Gaffer installed. We're releasing new versions of Gaffer sufficiently regularly that this is becoming too much of an overhead - particularly when combined with IE's "dev" version suffixes, which force a developer to have local installs of all dependent projects.

This commit marks major version 1, and we will now always increment the major version whenever introducing any backwards-incompatible change. As we may break compatibility fairly regularly, and often breaks due to refactoring don't actually provide significant functionality, standard semantic versioning would lead to version numbers which aren't particularly useful to the casual user - they would increment regularly but the user would see little change in practice. We've therefore adopted an additional version prefix - the "milestone" version. We'll bump this whenever Gaffer reaches significant milestones in terms of functionality and we wish to shout about it and otherwise draw attention to ourselves. The current version is 0.1.0.0, indicating that we don't have much to shout about yet.

It's critical going forwards that we correctly increment the right version numbers, and describe thoroughly the nature of incompatible changes in commit messages so that they can be collated into a suitable section of the subsequent release notes.

A new Version.h header file provides a GAFFER_COMPATIBILITY_VERSION macro, which combines GAFFER_MILESTONE_VERSION and GAFFER_MAJOR_VERSION into a single number suitable for use in conditional compilation.

At Image Engine we can now create a $GAFFER_COMPATIBILITY_VERSION environment variable (which would initially be 0.1), and use that for the installation of dependent tools, reducing the overhead in managing development builds.

Fixes #980.