Feature/faster python build

[staleyLANL]

This change may raise some eyebrows. It arguably thumbs its nose at the normal build-system concept of fine-scale recompilation: compile only the individual translation units that have changed since the last build. However, I believe the new system is much better, given the circumstances. (More below.)

The old system is still available with: make -j <threads> GNDStk.python.old.

For the new system, just use this: make GNDStk.python.

No -j is necessary for the new system. It doesn't help.

Timings on the author's office machine, with make -j 24:

 * old: 735.93 seconds.
 * new: 221.25 seconds.

Additional benefits:

 * Less memory, overall, appears to be used.
 * Only one thread is needed. (This also frees up memory.)

Moreover, the resulting .so file is less than half of its original size! On the author's office machine:

 * old size: 221,451,008 bytes.
 * new size: 106,036,816 bytes.

Why does the size improve so much? My guess is that this relates, in part, to lambdas. Consider that two classes, X and Y, may both contain an object of class Foo. Foo's functionality may use lambdas. Internally, compilers handle lambdas by generating anonymous classes with call operators. Compile files individually,and multiple anonymous classes (and thus operators) for Foo may be created. As they're anonymous, we won't get multiply-defined symbol errors when linking. But, the same thing may be repeated in multiple files, whereas more efficiency can be obtained with the new system. (This theory about lambdas being the cause may or may not be correct. Regardless, the new .so file's size is much smaller, at least on my machine.)

So, what's the new system? Well, we made a file,

 python/src/all.python.cpp

that includes all of the *.python.cpp files - a total of 280 files - that were previously compiled individually. Stuffing these together is fine, from a technical standpoint, because of course we have macro guards on all the header files that those source files include, and we don't have file-scope statics or other things that might cause issues.

This process - stuffing C++ files together - flies in the face of the normal build concept, but (if the above stats aren't convincing enough), we believe it may be the best approach here.

 * Users are likely to download GNDStk, compile once, and then not bother
   doing so again until a substantial new release comes along. Enough
   things are likely to change, between substantial releases, that most
   individual files - not just a few - may have changes, and thus need
   recompilation, anyway.

 * Users may now see, for instance, 6 minutes instead of 20. Yay!

 * Most `*.python.cpp` files are autogenerated. If one such files changes,
   it's likely that most others have changed similarly, due to some change
   in the code generator's behavior. In this case, there's no big benefit
   to a fine-scale recompilation.

The big issue is this: GNDStk is a large header-only library, and its header is included in all of the *.python.cpp files. The author's long experience with such situations has been that the processing of the header (including what it additionally includes, such as the JSON library) - translating from code to an AST (abstract syntax tree) - eats up most of the compilation time. Basically, in our old system here, the same processing was being done 280 times, each time followed by typically just a page or two of code in the *.python.cpp file itself! So, a fine-scale-compilation system is dominated by overhead. The same overhead, 280 times!! :-( Stuff the files together, and the header processing happens only once.

I'd suggest that in all but rare (and probably contrived) circumstances, the new system will be faster than the old system, and also use less memory. And, it'll always need only one thread, and give a smaller-sized .so file.

Note: the code generator can be modified so that it automatically puts together the individual source files that currently appear in python/src/all.python.cpp, except for the non-autogenerated ones at the top. In this case, we could then have python/src/all.python.cpp include the non-autogenerated ones, as they do now, plus a single extra file. At the moment, I haven't modified the code generator to do this.

[staleyLANL]

Remark. The CI is still failing. With the new system, we could see if a plain make, rather than a make -j 2, succeeds. Only one thread is necessary for GNDStk.python. It may or may not use less memory than the -j 2 case, though.

Another remark. Other NJOY codes that are similar in certain respects (have python bindings, binding files unlikely to change on a fine scale, many such files, each including a relatively long and complex header for which processing overhead is large) may show similar build-time improvements if we do something similar to what I did here. We'd just need to try, in order to know. Aside from build-time improvements, other improvements may include needing only one thread, using less memory, and producing substantially shorter archive files.