Windows: Fix inconsistent behavior on changes to case of path to cmake

In commit v3.4.0-rc1~333^2 (Merge branch 'upstream-kwsys' into
update-kwsys, 2015-07-15) we brought in upstream KWSys commit 86a24794
(SystemTools: Fix GetActualCaseForPath drive letter case handling,
2015-07-09).  This caused our path processing to convert drive letters
to upper-case and exposed an existing bug in our implementation of
CMP0017.

Policy CMP0017 is responsible for ensuring that modules included from a
builtin module only load other builtin modules and cannot be overridden
by a file in `CMAKE_MODULE_PATH`.  If there is a case difference in the
drive letter (or other path components) then the path to the including
module may not match our builtin module directory in a simple string
comparison.  This means builtin modules may not be recognized as such,
and they may not reliably include their builtin dependencies.  For
example, if a project provides a `Platform/Windows` module in
`CMAKE_MODULE_PATH` it can break inclusion of our builtin
`Platform/Windows` module, leading to strange behavior.

Fix this by comparing the path to the including module to our builtin
module directory using a function that is aware of case-insensitivity of
paths on Windows.

Fixes: #16648, #16622

Source/cmMakefile.cxx

@@ -3362,7 +3362,7 @@ std::string cmMakefile::GetModulesFile(const char* filename) const
   if (!moduleInCMakeModulePath.empty() && !moduleInCMakeRoot.empty()) {
     const char* currentFile = this->GetDefinition("CMAKE_CURRENT_LIST_FILE");
     std::string mods = cmSystemTools::GetCMakeRoot() + "/Modules/";
-    if (currentFile && strncmp(currentFile, mods.c_str(), mods.size()) == 0) {
+    if (currentFile && cmSystemTools::IsSubDirectory(currentFile, mods)) {
       switch (this->GetPolicyStatus(cmPolicies::CMP0017)) {
         case cmPolicies::WARN: {
           std::ostringstream e;