Prepare for the change of the NAMD reduction interface

[HanatoK]

David Clark from NVIDIA is working on extending the GPU-resident code to multiple nodes. He has proposed to refactor and unify the reductions of energies and virials in NAMD, as the old NodeReduction class only works for the single-node code path. I have proposed to change NAMD_VERSION_NUMBER to 34471682L after David Clark's MR (see https://gitlab.com/tcbgUIUC/namd/-/commit/e81f36cc733d884f2aa2699449a61fa4c68483dc on a hackathon branch). This PR changes the colvarproxy_namd.* to check the NAMD_VERSION_NUMBER to determine whether NodeReduction should be used.

[giacomofiorin]

I saw your MR on NAMD, and wanted initially to comment there, but here it would be better (public repo). That magic number was initially intended to comply with an upcoming change in NAMD to represent internally its version with an increasing integer. Unfortunately, that MR was never merged.

The number 34471681 that we currently have is for 2.14b1:

>>> print(int.from_bytes(int(2).to_bytes() + int(13).to_bytes() + int(255).to_bytes() + int(1).to_bytes()))
34471681

(note that the second byte is 13, i.e. one less because the beta version should precede 2.14).

Following that version scheme, and assuming that eventually it may be adopted by NAMD, you could probably use 3.1a2 for all code that is being integrated into NAMD main in the near future?

>>> print(int.from_bytes(int(3).to_bytes() + int(0).to_bytes() + int(254).to_bytes() + int(2).to_bytes()))
50396674

Alternatively, if that NAMD version scheme is being abandoned, we could just use a preprocessor flag for that specific feature?

#ifdef NAMD_UNIFIED_REDUCTION
 ...new code...
#else
...old code...
#endif