Future NetCDF variable promotion.

This PR enhances the netCDF loader to allow it the ability to automatically promote the reference surface variable associated with a dimensionless vertical coordinate.

This functionality is exposed to the user via the `iris.FUTURE` API and the controlled attribute `netcdf_promote`. This permits the following usage:

 * Use the netCDF loader as normal, with no variable promotion:

```python
cubes = iris.load(fname)
```

 * Turn-on, and keep on, variable promotion until explicitly turned-off:

```python
iris.FUTURE.netcdf_promote = True
cubes = iris.load(fname)
...
iris.FUTURE.netcdf_promote = False
```

 * Turn-on variable promotion limited to within a context scope:
```python
with iris.FUTURE.context(netcdf_promote=True):
    cubes = iris.load(fname)
```

The `iris.FUTURE` approach was adopted rather than explicitly naming netCDF variables to promote, as the user may not know beforehand, the names of the variables that require to be promoted to cubes. It also avoids the propagation of `kwargs` down through to the loader.

Note that, a specific promoted variable cube may be targeted using the standard constrained loading mechanism:

```python
with iris.FUTURE.context(netcdf_promote=True):
    cube = iris.load_cube(fname, 'sea_surface_height_above_geoid')
```

Closes #1070.
This function modifies the `ignored` variable (defined in this scope), but you don't pass it it as a argument. Is that intentional? My issue is that subsequent calls to `build(var)` will continue to add to ignored, even the one in the loop iterating through `ignored`. Presumably this is intentional and I can see the benefit (it''l keep digging through nested dependencies), but without passing ignored as an arg it could be seen as an accidental side effect rather than intended behaviour. Continuing to append to `ignored` in the loop on line 1066 might also raise the potential for circular references that might cause an infinite loop of building? Thoughts?