Re-add 'main' conda-forge channel; fix for eccodes >= 1.19

[pp-mo]

This fixes the RTD docs-build error which emerged following the cut of the original 0.16.0rc0 pre-release tag.

Given the error seen in the attempt to re-spin #224 today, we suspect those errors will come through here too
(something to do with ellipsoid definitions changing)
So we will probably want to wait until that is fixed before merging this ...

[pp-mo]

Ok, so the key problem is that ECMWF have changed a default parameter setting for GRIB1 messages.
I'm not sure quite how this works, but it looks like 'shapeOfTheEarth' used to be defined as '6' but is now '0'.

All the problems are with GRIB1 files in iris-test-data, that now read back differently,
for example <testdata...>/GRIB/rotated_uk/uk_wrongparam.grib1
I can't find any specific reference to the 'shapeOfTheEarth' in the GRIB1 specifications, so I think this is a case where the gribapi returns a grib2-style parameter for a grib1 message "as if" it had that meaning.
Such attempts, to leverage the gribapi "generic" view of data, were our whole problem with the original iris grib interface, which led to its replacement with the 'strict' grib loader (i.e. the code based on GribMessage not GribWrapper).

From comparing release downloads of eccodes, the key change seems to be in a file definitions/grib1/section.2.def
At version 1.18 this reads...

# START grib1::section
# SECTION 2, Grid description section
#  Length of section

position offsetSection2;
 . . .
transient shapeOfTheEarth=6 : hidden;

Whereas in 1.19 this last line changed to ...
transient shapeOfTheEarth=0: hidden; #ECC-811

In the release notes , Bug Fixes section, we have
"[ECC-811] - shapeOfTheEarth=6 for GRIB1"

Unfortunately the issue content may be private -- I can't view it but @lbdreyer can ?

[pp-mo]

I've posted a 'fix' to that gribapi change.
From discussion with @lbdreyer, our main priority right now is backwards-compatibility.
We can discuss later whether this was always really wrong and should in future be fixed.

[lbdreyer]

Is this intentional, you are hardcoding soe_code to be 6, but including the if soe_code == 0 for future, if we decide to change it?

[pp-mo]

Yes, I thought I should remove most of the previous unused options, but I left both these ones in for reference.

[coveralls]

Coverage increased (+0.3%) to 92.827% when pulling 063a6a3 on pp-mo:fix_channels into 5a96b74 on SciTools:v0.16.x.

[lbdreyer]

Looks good to me!
As @pp-mo says I think we need to prioritise minimal change for this release.
We would first need to understand the impact of changing to the new default (covered by #241), i.e. how many users would it upset as they expect the old, incorrect default, and as we're pressed for time right now, I don't think this is the right time.