Low-level FieldsFile variant access

**Work-in-progress**

This PR demonstrates a possible low-level API for reading UM FieldsFile variants - instantaneous dump, mean dump, "normal" FieldsFile, ancillary, etc.

The main open questions are around how to handle the DATA component and its relationship to the LOOKUP component.

Example usage:
```python
from iris.experimental.um import FieldsFileVariant

path = '/data/local/dataZoo/Fields/lsm/qrparm.mask'
ffv = FieldsFileVariant.from_filename(path)
print ffv
print 'Sub-model:', ffv.fixed_header.sub_model
print 'ints:', ffv.integer_constants
print 'reals:', ffv.real_constants
print 'levels:', ffv.level_dependent_constants
print 'lookup shape:', ffv.lookup.shape
print 'data shape:', ffv.data.shape
print
print 'LBLREC:', ffv.lookup[14, :]
print 'LBPACK:', ffv.lookup[20, :]
```
Resulting in:
```
<FieldsFileVariant: dataset_type=4>
Sub-model: 1
ints: [-32768 -32768      1 -32768 -32768    940   1016     38 -32768 -32768
 -32768 -32768 -32768 -32768      1]
reals: [ -1.07374182e+09  -1.07374182e+09  -1.07374182e+09  -1.07374182e+09
   3.75000000e+01   1.77500000e+02]
levels: None
lookup shape: (64, 1)
data shape: (955040,)

LBLREC: [955040]
LBPACK: [0]
```
Another good spot :wink:, I'd ignored those for now because they weren't critical.

But actually they're part of a wider pattern, in that the meaning (and hence the name that should be used) varies for different variants. For example, depending on variant what is currently listed as "misc_validity_time" means either "wall clock time of file creation" or "interval between validity times". This also happens with some of the other single-word quantities. I'm inclined to err on the side of dropping the names for such quantities and just providing raw array access.