Document fast fieldsfile loading.

> what you mean by 'should', where above you've used 'must'.

I think that's the whole big problem here :  I've been using "should" precisely where I want to be a bit vague about the implications, and subtly put the onus on the user to avoid those cases.  It starts with the blanket "files *should* conform to the following requirements".
If I say "must" everywhere, I think that implies it will fail or warn if the input does not conform -- or at least, that it ought to (which I somewhat believe myself).  Instead, at present, many failures will be silent because we don't check everything.
Because of this, I'm thinking the best thing we can do is to remain a little vague about the results of breaking the rules.  Hopefully, the warning acts as a catchall for these problems.

I'm frankly not that comfortable with the existing behaviour in this respect, as when the input does not "obey the rules" we are currently ignoring the fact in many cases.
Examples : 
  (1) "other" header elements are not checked to be all the same,
  (2) additional vertical level data is all copied from certain fields without checking to see if it actually has the expected repeating structure (as found from BLEV).

I still believe there may be ways of checking the assumptions which would not be too inefficient, and we should probably look into that.