Support for R-4.2.0

[amirmasoudabdol]

For the most part, I expect things to work. but on Windows, I'm running to some issues compiling R-Interface. I need to investigate this a bit more, but I feel we need to add a few extra flags for the compiler to be more specific, and I've not found them so far.

In addition to upgrading R-4.2.0, this PR includes the following:

• CMake now downloads the gfortran from statics.jasp-stats.org as well
• MSYS2 will be replaced by Rtools42. This was not possible before, but the new Rtools is much nicer to work with, and it can be used to install new Boost, jsoncpp, etc.
  • All the references to the MINGW are (will be) replaced by RTOOLS
• Fixed a few bugs that could have made CMake picking up the wrong library when building the R-Interface.
  • Specifically, I'm not linking to the libboost_nowide directly instead of relying on CMake to find it.
• Replaced the JAGS pre-built with the newer version built using Rtools42

Know Issues,

• On macOS, if any of the jaspBase requirements need building then the install-jaspBase.R will fail, and therefore the build fails. This is due to the strict signing requirement on macOS; and it is most likely going to be resolved by more packages having their build on ARM sort out.
  • Building fails because as we install packages, we patch them, therefore breaking their signature and since unlike jaspBase::installJaspModule where we sign them using the JASPEngine right away, here, install-jaspBase.R cannot do that, and therefore we have an unsigned library which R cannot load.
  • @vandenman proposed that we can take out the installJaspModules and make it a standalone script that we can just use in install-*.R files. I think this is a good idea, and will resolve the issue but it might need to wait for now.

Things to do,

• Since, we have the UCRT build, we can probably remove bunch of legacy code; but I don't think I have time for that. I make sure that the build is smooth, and leave the rest to others.
  • For instance, I'm not sure if we still need the Boost::nowide or not.

[amirmasoudabdol]

As I was expecting, some of the changes here are fixing the issue that Koen ran into. While I'm still not 100% sure, I suspect that part of the issue was that when passing the build to the R-Interface, CMake was getting confused a bit on what's what, and was picking up the wrong Boost, and therefore R-Interface was ended up having slightly different ABI.

In this situation, I basically don't trust CMake to pick up the right Boost, and only check if libboost_nowide is there, and if it's there, and since that's the only thing we need, I just pick that one up, and link to it. So, I can be sure that I'm looking into the right place. If you decided that you don't want to go with the R-4.2, you can carefully cherry pick these changes, and reflect it to the development.