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.
Merge pull request #1767 from fontforge/frank_redhat_2

Conform Red Hat packaging metadata to new rules.
Remove more absolute symlinks from the source tree.
Merge pull request #1768 from fontforge/frank_redhat_2

Remove more absolute symlinks from the source tree.