Populate cube.fill_value thru cube.data setter.

[bjlittle]

This PR is a follow-on action from #2492 and detailed in #2516 and allows the cube.fill_value to be set from the fill_value of concrete masked data being passed to cube.data setter.

All of the CML changes are due to either tests directly setting cube.data with a masked array, or tests that use testing stock cubes that set cube.data directly with a masked array ... thus populating the cube.fill_value and thus bleeding thru to the CML. This is the behaviour that we want to see.

If data passed to the cube.data setter is not masked data, then the cube.fill_value will be clear, as before.

This PR also neatly completes the circle with fill_value and masked arrays wrt the cube, in that the cube.data getter will set the fill_value of any masked array returned to the user with the cube.fill_value, and now this PR allows the fill_value of a masked array to set the cube.fill_value through the cube.data setter.

[bjlittle]

Ping @dkillick and @lbdreyer ...

[lbdreyer]

If you create a new masked array with a specific fill value, make it lazy, then make it a cube's data
cube.data = lazy_array_that_was_originally_masked_with_a_fill_value
the fill value will get lost, but I guess there's nothing we can do about that and probably not something we need to account for

[lbdreyer]

This looks good to me 👍 So unless there are any objections I'm going to merge this in!

[lbdreyer]

This doesn't check the data type of the fill value is correct but presumably the testing of that will be in the cube.fill_value setter

[bjlittle]

My assumption is that unit testing elsewhere covers that, and it does 😉

[bjlittle]

@lbdreyer Awesome, thanks!

[lbdreyer]

I'm having second thoughts on this PR...

1. It has introduced a disparity between cube.fill_value behaviour depending on whether you instantiate a cube with a masked array or add it to a cube already there, i.e.:

>>> data = np.array([1, 2, 3])
>>> masked_data = ma.MaskedArray([1, 2, 3], mask=[True, False, False])
>>> 
>>> cube = Cube(masked_data)
>>> print cube.fill_value
None
>>> 
>>> cube = Cube(data)
>>> print cube.fill_value
None
>>> cube.data = masked_data
>>> print cube.fill_value
999999

2. I also noticed that it introduce some strange behaviour with one of our test files which has a dtype of unint8

>>> cube = iris.load_cube('iris-test-data/test_data/abfAVHRRBUVI01.1985apra.abf')
>>> print type(cube.data)
<class 'numpy.ma.core.MaskedArray'>
>>> print cube.fill_value
None
>>> cube.data = cube.data.copy(order='C')
>>> print cube.fill_value
63

This is because, regardless of what type of integer the masked array's dtype is, the fill_value of an integer masked array will always be 999999 (:warning:)
The cube's data in the above example is a masked array with a dtype of uint8 so the cube.fill_value setter is changing the default numpy fill value to be 63:

>>> np.array([999999], dtype=np.uint8)
array([63], dtype=uint8)

[bjlittle]

@lbdreyer Nice detective work! Let's discuss a way forward off-line and commit to a follow-on PR 👍