Falcon stdc++17

[jcldc]

In this branch, the Dehnen code (falcON) is now compatible with the C++17 standard. When compiling, there are practically no more warnings, both with g++ (Linux) and with clang++ on Mac Intel/ARM.

In the make.gcc and make.clang configurations files, I have forced the C++11 standard because some compilers are not yet C++17 compatible.

[teuben]

The VERSION is still 3.6, we should change that.

The "make check" and "make bench5" didn't' show any issues, but I found a small difference in the final result of another test done, two ways:

mkplummer /tmp/p1000 1000 seed=1000
gyrfalcON /tmp/p1000 . eps=0.05 tstop=10 kmax=6

old: 10.000000000 -0.2313544935 0.2377831 -0.4691376 -0.4676625 1.0169 0.01568 3.2e-08   4 10  0.00  0.00  0.00   0:00:00.63
new: 10.000000000 -0.2313409586 0.2377885 -0.4691295 -0.4676696 1.0169 0.01568 1.6e-08   4 10  0.00  0.00  0.00   0:00:00.63

mkplum /tmp/p2000 2000 seed=2000
gyrfalcON /tmp/p2000 . eps=0.05 tstop=10 kmax=6

old: 10.000000000 -0.1406786710 0.1399422 -0.2806209 -0.2802907 0.9986 0.01564 0.00508   8 13  0.00  0.00  0.00   0:00:01.21
new: 10.000000000 -0.1406786360 0.1399423 -0.2806210 -0.2802907 0.9986 0.01564 0.00508   8 13  0.00  0.00  0.00   0:00:01.21

I ran this on Ubuntu 22.04 with g++ 11.4. Will also test with a g++ 14

[jcldc]

For the diferrences, they are very small. It can be the result of the compilation with "-std=c++11", plus some modifications. It does not seem to be critical.
For the Version number, well, it could be 3.7.

[jcldc]

Btw, to be compatible with c++17, I had to remove some "register" keyword, which could be why there are some tiny differences in the results.

[teuben]

version really is a MUST!

Although the differences are small, the regression test is being run with "make check" does not show any differences. Quite puzzling. Regression is on a 1024 plummer, to tstop=2, and the Etot shows a difference in the 9th decimal instead of the 8th.