Improve FONTLOG-related workflow and tooltip
Improved content and layout of OFL button and tooltips (fixed the repeated lines)
Added typo fix and trailing line fix
Make text lighter and more in tune with practical steps
Added missing newline
Add some comments relevant to class kerning.
Guard against crashes when "Guide" layer active

This change implements checks against crashes in some vulnerable routines
that can fail when the current displayed layer in CharView is the
"Guide" aka 'grid' layer.

Testing of various UI actions revealed that these routines would crash
using the layer index value -1, which is the 'grid' layer index:
   fontforge/cvundoes.c    SCPreserveHints()
   fontforge/splinechar.c  SCNumberPoints()
   fontforge/autohint.c    _SCClearHintMasks()
   fontforge/stemdb.c      GlyphDataInit()
   fontforge/cvhints.c     SCModifyHintMasksAdd()
Code was added to these routines to simply return if the layer value
was outside the valid range for the layers array.

During testing using Python scripts a further set of problem routines
were identified in python.c and fixes applied.

Finally, the original investigation found a number of places where code
was using "magic numbers" that were equivalent to the `enum layer_type`
values defined in splinefont.h.  This obscured the intent of such code
and enum definitions were used to replace those numbers (-1, -2, etc.)

Tested with debug printf()'s to demonstrate usefulness, with all these
added checks being hit and preventing crashes.

"Doctor Doctor when I touch my head it hurts. When I touch my arm it hurts. When I touch my knees it hurts." The doctor replied, "You have a broken finger."
Python script crash on 'empty' contour/layer/glyph

While investigating issue #1750 and trying to test scenarios with scripts,
I found vulnerabilities when certain Python scripting APIs were called
with empty ('new') FF objects.  Internal routines would return NULL
pointers in consequence of the empty objects but sometimes calling code
would not guard against these, and following calls would crash trying to
use the NULL pointers.

This change fixes the following scenarios:
```
    contour1 = fontforge.contour()
    contour1.is_quadratic = 1

    contour1 = fontforge.contour()
    contour1.spiros()

    layerEmpty1 = fontforge.layer()
    layerEmpty2 = fontforge.layer()
    layerEmpty1.stroke("polygonal", layerEmpty2)
```
The last example pattern is seen for all three of `contour`, `layer`, and
`glyph`.

All these combinations (and many others) were tested and no longer crash,
or were proven not to crash originally.

Additionally, another crashing scenario with an empty tuple was found:
```
    contour1 = fontforge.contour()
    contour1.spiros = ()
```
This change fixes that problem by simple checking for empty tuple.
Merge pull request #1755 from tshinnic/1750_invalid_layer_index_2

Guard against crashes when "Guide" layer active
Merge pull request #1759 from tshinnic/python_spiro_null_checks_1

Python script crash on 'empty' contour/layer/glyph/tuple
Add support for import and export of U. F. O. groups and group kerning rules.
Work around the bootstrap state problem by deleting the config files before packaging.
Remove generated bootstrap files from the tree.
SFD unpickle usage outside of Python scripting crash

This change fixes the issue #1756 "why this script failed to generate
ttf for oxygen-fonts?"

There are a number of ways that embedded Python is used from FontForge,
such as script files, source from STDIN, entered via UI dialog, and
even via a socket (!?).  And also it can be used as part of a convenient
way to encode/decode complex object data through SFD files, in font and
glyph `PickledData:` sections.

When native scripts were used with FontForge, the embedded Python was not
initialized for running, because it wasn't going to be used. :)  Except,
if the script was opening SFD files that happened to contain `PickledData:`
sections, fontforge/sfd.c `SFD_GetFont()` and `SFDGetChar()` routines
would call `SFDUnPickle()` and thence `PyFF_UnPickleMeToObjects()`.
Trying to use the Python pickle/unpickle APIs without having initialized
Python would then crash.

This change simply adds a call to `FontForge_InitializeEmbeddedPython()`
to the initialization of the FF pickle/unpickle routines.  It does not
address when the now needed Python cleanup at program end should happen.

This change should logically also address part of issue #1687, but it
seems that the problem there is not completely covered by this fix.

Tested with both Python 2 and 3, with native and Python scripts, and
using the UI.
Merge pull request #1765 from tshinnic/1756_1687_pickled_python_poof_1

SFD unpickle usage outside of Python scripting crash
Merge pull request #1761 from fontforge/frank_redhat_2

Fix Red Hat packaging.
Python minor cleanups

Noticed redundant #ifndef's during investigation of #1756.  Since almost
all code within fontforge/python.c is surrounded by `#ifndef _NO_PYTHON`
it was strange to see individual bits of code surrounded by additional
such `#ifndefs`

Also, one copy-n-paste was one line too low, with an `exit(0)` before it.

And just happened to notice an extra unneeded declaration in
fontforgeexe/startui.c  Do modern C compilers just drop those?  And wow,
Coverity didn't complain either.
Python Py_BuildValue() bad zero values

Reading through old changes to fontforge/python.c I saw change 94b6ccb9484eb85fe25c5e127ce33175e1118a67
which intrigued me, telling me something I didn't know about using the
Python C API Py_BuildValue().  His descriptions included
> Integers being incorrectly passed to Py_BuildValue() expecting double.
>   The fix is to substitute 0.0 for 0 in these arguments, which C treats
>   as constant of type double.

But when you find one instance of a bad pattern, you should worry
whether that same goof was reproduced in multiple.  (Un?)fortunately
this same mistake was found in 3 more places.  These were changed
like this:
>     return( Py_BuildValue("(dddd)", 0,0,0,0 ));

to
>     return( Py_BuildValue("(dddd)", 0.0, 0.0, 0.0, 0.0 ));

One instance was easily tested, and indeed found to be broken and then
fixed by this change:
>  contour.boundingBox() returned '(6.91320453175617e-310, 6.91320569035315e-310, 6.9132056837544e-310, 1e-323)'

vs.
>  contour.boundingBox() returned '(0.0, 0.0, 0.0, 0.0)'
Merge pull request #1766 from tshinnic/python_cleanup_misc_1

Python cleanup misc 1
Adjust Red Hat packaging metadata in order to support new rules on file inclusion.