CMake: don't use configure_file() with filenames containing genexprs.

On multi-config builds this was putting __init__.py into a directory
named $<CONFIG>. Which, funnily enough, worked on Linux, but still caused
an issue when actually installing the package, as __init__.py was then
missing from the proper location. On Windows this blew up when attempting
to create that directory in the first place.

This is broken since e5e7824b96, and this
fix is what that commit should have been instead -- adding the `.in`
suffix to the configure_file() output as well to prevent it from being
interpreted by Python.

That commit is from January, and I'm terribly sorry for this regression
being here for so long. The reason it went unnoticed is that none of the
CI jobs use a multi-config build (which I ultimately have to fix) and my
local Ninja Multi-Config build directory worked only because it was
containing the original __init__.py file from before that commit, and I
didn't recreate the build directory since. Heh.

src/python/corrade/CMakeLists.txt

@@ -112,8 +112,16 @@ if(MAGNUM_BUILD_STATIC AND UNIX AND MAGNUM_BUILD_PYTHON_BINDINGS_RTLD_GLOBAL)
 else()
     set(_MAGNUM_BUILD_PYTHON_BINDINGS_RTLD_GLOBAL "## ")
 endif()
+# ${output_dir} contains $<CONFIG> on multi-config builds, and configure_file()
+# cannot expand that during the configure step so it has to put the result into
+# a temporary location and then file(GENERATE) does the rest. It's important to
+# ensure that the file put in ${CMAKE_CURRENT_BINARY_DIR} isn't named
+# __init__.py as that may cause Python to wrongly treat the directory as a
+# package, which it isn't.
 configure_file(${CMAKE_CURRENT_SOURCE_DIR}/__init__.py.in
-               ${output_dir}/corrade/__init__.py)
+               ${CMAKE_CURRENT_BINARY_DIR}/__init__.py.in)
+file(GENERATE OUTPUT ${output_dir}/corrade/__init__.py
+    INPUT ${CMAKE_CURRENT_BINARY_DIR}/__init__.py.in)
 
 pybind11_add_module(corrade ${pybind11_add_module_SYSTEM} ${corrade_SRCS})
 target_include_directories(corrade PRIVATE