Add data attribute to FieldCollation

Adds a data attribute to `FieldCollation` so that the data in the input PPField iterator can be accessed by downstream consumers of `FieldCollation` objects.
@dkillick :bomb: ... Dah!

I'm seeing some interesting behaviour downstream in `fileformats.rules._make_cube` which accesses the data:
```
def _make_cube(field, converter):
    # Convert the field to a Cube.
    metadata = converter(field)

    try:
        data = field._data
    except AttributeError:
        data = field.data
```

As you can see, `_make_cube` tries to first access `field._data` ... we're totally guilty of shooting ourselves in the foot here! Your `data` property API on `FieldCollation` is sound but of course at this point `field._data = None` as we're exposing the data through the controlled `data` property, which populates the `_data` instance member under-the-hood on first invocation.

As `FieldCollation._data` does indeed exist and is initially set to `None`, then `data = None` is passed into the `Cube` which raises an exception, as you might expect, when we attempt to decorate it with coordinate metadata.

Rather than change `_make_cube` you could simply not cache the data in `FieldCollation._data` but say `FieldCollation.__data` ... ? Others may object to this suggestion ...

Or you could change `FieldCollation` thusly:

```
    @property
    def data(self):
        if not self._structure_calculated:
            self._calculate_structure()
        return self._data

...

    def _calculate_structure(self):
        ...
        # Populate the data structure.
        data_arrays = [f._data for f in self.fields]
        self._data = ArrayStack.multidim_array_stack(data_arrays, self.vector_dims_shape)
        # Do all this only once.
        self._structure_calculated = True
```

On reflection, I prefer the second approach, rather than the utilise `__` magic!