Low-level write access to UM FieldsFile variants.

This PR intends to be a reasonable first stab at providing the ability to modify/create UM FieldsFile variants.

As a low-level API it does not guarantee that modified/created files are strictly compliant with the official format documentation. However, it does perform a bare minimum of consistency checks/updates for metadata elements which dictate the locations of the various sections within the file, and which would be tedious and error prone to perform "by hand". The elements affected are the start and dimension length elements within the fixed length header, and the LBEGIN and LBNREC elements within the LOOKUP entries.

NB.
 1. No support is provided for packing data. Unless the "N1" digit of `field.lbpack` is zero the file will not be valid.
 2. This PR requires SciTools/iris-test-data#32 to be merged for the tests to pass to without "naughty" modifications to .travis.yml.

 - [ ] Update .travis.yml once test data has been merged.
> The only values in the fixed length header which get changed are those which relate to the locations within the file.

That sums it up nicely and my mind would be put at ease if the doctoring for the `close()` method made a note that this (necessary) modification to the header takes place prior to writing to disk. I'm just concerned about exposing the header, letting the user modify it in lots of ways, but then the header changing as a side effect of calling `close()`. It's unavoidable, so I suggest we just document the behaviour.