UM fields array structure identification for fast loading.

Context: 
The key external interface is "group_structured_fields"  (in iris.fileformats.um._fast_load_structured_fields).
 * this returns 'FieldCollation'-s ..
 * .. which are in effect triples of (vector_dims, dimension_elements, element_arrays_and_dims)
 * .. so something else can turn that information into cubes.

There is no actual user API yet. 
Most probably will be an experimental 'iris.load'-like function, which will take filenames + return cubes.
> @pelson It would be nice if this were easy for the user to override

Don't forget that this a private module : We still have no public API and
we haven't yet got a design for what that might look like.

> @pelson In general, this is too simplistic

I took advice from @marqh on this, and he was definite that we should include
only the minimal terms at this point, and that by using this the user effectively
"asserts" that the data is suitable.  This is what the original development
ticket states.
However, I am myself suspicious that this may be optimisation before the need
is proven:  I think it could well **not** be overly inefficient to include all
relevant (non-vector) metadata in the classification process, as this supposes.
I believe we should test that when we have a complete functioning solution.
Also, even if _classifying_ more metadata proves too expensive, it might well be possible to write a fast check that the remaining elements
(relevant, non-vector, non-classified) are everywhere the same.

However, having said all that, I believe the main reason to take the minimal
approach for now is simply that we have no good way of _distinguishing what
header elements may be "relevant" from the ones we must ignore_ (because the spec is too loose). 
This is exactly what I am trying to explain in the docstring to
"group_structured_fields".