Check consistency of encoding slot counts on input and output, and document it

It is possible for something that otherwise resembles an SFD file to specify a number of encoding slots less than the minimum required by the encoding it specifies.  Since the number of encoding slots is used to allocate arrays, this inconsistency will eventually lead to segmentation faults as FontForge tries to index outside the allocated arrays (see issue #515); but a crash is not guaranteed because not many operations actually try to access unused slots.  A file *originally* created by FontForge is unlikely to ever contain this problem, but because current FontForge doesn't check for it on input or output, FontForge can load an invalid file originally created by other software, save it without crashing, load the still-invalid result, and then crash.

Related issue: because encodings like UnicodeBmp specify semantics for what the slots *mean*, FontForge may reorder and renumber glyphs if their ordering in the input file doesn't match what the encoding requires, and that may be undesirable in some situations.  See issue #518.

This patch:

* Adds a paragraph of documentation to advise authors of other SFD-writing software of the consequences of choosing encodings like UnicodeBmp with slot-count and ordering requirements, and recommending the use of other encodings if necessary;
* Adds a check for this kind of inconsistency on SFD load, with a fatal error if it's detected; and
* Adds a check on save, automatically increasing the count to the minimum should it be less.  This is probably redundant once we're checking on input, and I'm not certain it can fix all cases of invalid in-RAM data structures, but it may reduce the potential for future problems if any ways remain to create an inconsistent data structure (for instance, by loading some future non-SFD file format).

Thanks are due to @ilyaza for reporting the related issues.