Support CMake-only build and submoduling.

[pvc1989]

This request has already been proposed in #2 and #7.

The main reason (as I understand) to use a Makefile as a preprocessor is to prepend two #define lines to metis.h, which then might be installed somewhere (currently in ~/local by default). As @karypis mentioned in #2, the attempt made by @zheng-da leaves the burden of defining these macros to the user of (the installed) METIS, since the installed metis.h, which is copied from the source directory, has commented out these two lines.

My attempt is based on the configure_file() command, which sets the values of IDXTYPEWIDTH and REALTYPEWIDTH in the configuration stage. The configured metis.h, which contains the two #defines, will then be used to build the targets in this project, and will be copied to ${CMAKE_INSTALL_PREFIX}/include in the installation stage. At the point of running make install or ninja install (as mentioned by @gruenich in #7), my approach has the same effect as the current Makefile-driven one.

[pvc1989]

The second commit is to fix another tiny problem about CMake.

When someone build METIS as a stand-alone project, both ${CMAKE_SOURCE_DIR} and ${CMAKE_CURRENT_SOURCE_DIR} point to the top directory of METIS. Everything is OK.

However, if someone use METIS as a submodule of another project, say "ABC", then ${CMAKE_SOURCE_DIR} will point to the top directory of ABC, which means ${CMAKE_SOURCE_DIR}/GKlib will be ABC/GKlib, rather than ABC/METIS/GKlib or ABC/ThirdParty/METIS/GKlib.

This can be fixed simply by replacing ${CMAKE_SOURCE_DIR}/GKlib with ${CMAKE_CURRENT_SOURCE_DIR}/GKlib, since ${CMAKE_CURRENT_SOURCE_DIR} will be the top directory of the submoduled METIS.

[pvc1989]

The CMake-only build passed in all of the three typical operating systems, see this run in GitHub Actions for details.
At this point, non-cross-platform scripts (i.e. BUILD-Windows.txt, Makefile, vsgen.bat) can be git rmed from the root directory.

[gruenich]

Off-topic: Do you mind rebasing your branch and making a forced push? That would reduce this MR to three commits instead of having two merges from master sitting between your changes. Thanks!

[pvc1989]

Off-topic: Do you mind rebasing your branch and making a forced push? That would reduce this MR to three commits instead of having two merges from master sitting between your changes. Thanks!

Thanks for your advice. The commit history has been cleaned up.

[pvc1989]

The maintainer has made GKlib an external dependency. So this PR cannot been rebased on the targeting branch now.