BUG #13489. Fixing build issues when OpenGL is not found.

When OPENGL_gl_LIBRARY is not found, OPENGL_GLU_FOUND variable is not set at all
by FindOpenGL.cmake. That was causing errors indicated in BUG #13489. This
overcomes that issue.
Make the MFIX reader optional
Add MFIX reader to the XML only if it is enabled
Fix IdType to int conversion warning
BUG #13557. Fixed segfault in gmvread.c

    Correctly null terminate input directory string, especially when it has
    been set to a longer string previously.
STYLE: Avoid use of integer literals if a constant is available
DOC: Fixed document of cell type identifier

     Lines 5258 & 5260 clearly state cell type 4 and 6 for hex and pyramid, not
     vice versa.
COMP: Fixed a duplicate and a unused global variable declaration
STYLE: Declared constant variable as such
BUG #13558. Fixed segfault in gmvread.c for comment lines exceeding 99 chars

    Do not rely on fscanf() + a fixed length character array any more when
    parsing comments. Arbitrary comment line length supported now, as was the
    case with LLNL's GMV program itself.
BUG: Fixed uninitialized variable

     To avoid possible NULL pointer dereference for unstructured or logically
     rectangular grids
COMP: Silenced warnings about non-local variable using anonymous type
ENH: Store all gmvread.c error messages for possible later use in VTK code

     All error messages gmvread.c would send to stderr are suppressed by VTK.
     Store them such that meaningful error messages can be generated by VTK
     code.
BUG #13599. Fixed segfault while reading file with broken fromfile reference

    gmvread.c traditionally used to 'exit(0)' if a file referred to in a GMV
    file did not exist. Simply commenting out the 'exit(0)' statement (the
    strategy pursued in VisIt currently) led subsequently to attempts of
    reading from NULL stream with fscanf() and fread().
BUG #13635. Support absolute paths in fromfile on Windows

     Both <drive letter>:\ and \\networkname syntax supported now
STYLE: Use constant instead of hardcoded literals for data array names

       Material names, flag names etc. are user-defined names and used to be
       hardcoded to a length of 32 characters (plus null byte termination
       character). Use a constant now instead of the hardcoded '32' and '33'.
STYLE: Use constant instead of hardcoded literals for max. file name length

       A GMV file name and "fromfiles" referenced in a GMV file may at most
       consist of 300 characters according to this i/o library. Use a constant
       now instead of the hardcoded number.
STYLE: Use constant instead of hardcoded literals for max. keyword length

       GMV file format allows keywords consisting of at most 8 characters.
       Use a constant now instead of the hardcoded '8' and '9'.
ENH: Try to avoid heap overflows for too long file names & string values

     LLNL's GMV program (at least version 2.x up to 4.5) somehow managed to not
     crash while reading files with values subject to fixed length limitations
     (like values for keywords CODENAME, CODEVER and SIMDATE) that violated
     these limitations (e.g. "CODENAME foobar_version_2.1" exceeds the 8
     character limit of the file format specification.)

     So, there are quite a few legacy codes around that produce GMV files that
     are not 100% file format compliant and could cause VTK readers based on
     gmvread.c to segfault.

     Dito for GMV files with "fromfile" references longer than 300 characters.
ENH: Support GMV files with too long keywords

     LLNL's GMV program (at least version 2.x up to 4.5) somehow managed
     to not crash while reading files containing too long keywords (e.g.
     "endcomments" instead of "endcomm", "materials" instead of "material").

     So, there are quite a few legacy codes around that produce GMV files that
     are not 100% file format compliant and could cause VTK readers based on
     gmvread.c to segfault.