Windows compatibility fixes to FindHIP.cmake.

[ScottTodd]

See ROCm/TheRock#526 and ROCm/TheRock#583. Together, these changes help get the CMake configure + build steps for PyTorch on Windows further along.

Fix find_path search in the case where hipconfig with no suffix is not present

When using find_path, CMake searches for "a directory containing the named file". On Windows, hipconfig has three extensions: .bat, .exe, and .pl. None of these match the unsuffixed search pattern, so this adds a ${CMAKE_EXECUTABLE_SUFFIX} there.

Remove .bat suffix appending in favor of using the .exe discovered by find_program

The find_program(HIP_HIPCC_EXECUTABLE NAMES hipcc ...) and find_program(HIP_HIPCONFIG_EXECUTABLE NAMES hipconfig ...) commands should both find programs with the .exe suffix. Per the docs, they will not find programs with .bat or .sh suffixes unless those suffixes are explicitly requested: https://cmake.org/cmake/help/latest/command/find_program.html.

To search for scripts, specify an extension explicitly:

if(WIN32)
  set(_script_suffix .bat)
else()
  set(_script_suffix .sh)
endif()

find_program(MY_SCRIPT NAMES my_script${_script_suffix})

The code from 73b520a and 952028a appended a .bat suffix onto discovered file names where I believe the original names should just be used instead. I might be missing some edge case where .bat is needed, but I don't see any other context on those commits.

[marbre]

Whereas this should only upstream https://github.com/ROCm/TheRock/blob/46251085731276a9cef9be2a074e4ed9a4f77900/patches/amd-mainline/HIP/0001-Fix-FindHIP.cmake-search-for-hipconfig.patch I think it targets the wrong branch ROCM:docs/develop and therefore got into a weird state.

@ScottTodd do you prefer to update the target branch or should we reopen a PR?

[ScottTodd]

Whereas this should only upstream https://github.com/ROCm/TheRock/blob/46251085731276a9cef9be2a074e4ed9a4f77900/patches/amd-mainline/HIP/0001-Fix-FindHIP.cmake-search-for-hipconfig.patch I think it targets the wrong branch ROCM:docs/develop and therefore got into a weird state.

@ScottTodd do you prefer to update the target branch or should we reopen a PR?

The last time I sent a similarly simple change (#3785), I was informed privately to redirect to the docs/develop branch since that is the only branch that accepts contributions from public GitHub. Looks like the docs/develop branch was force pushed to since I opened this PR and no maintainers reviewed it. I can rebase or redirect as needed, but I can't do so without some guidance.

[ScottTodd]

Closing in favor of ROCm/rocm-systems#421