Switch to the new operations for obtaining OS handles

[jeltsch]

This is another attempt to solve the problem described in #185, one that neither introduces a dependency on Win32, as #185 does, nor on ghc-internal, as #186 does. This pull request introduces an alternative implementation of withHandleToHANDLE, which uses the new operations for obtaining operating-system handles that are provided by GHC merge request !14732. For converting from file descriptors to Windows handles, it continues to use the C function _get_osfhandle directly.

Please note the following:

• This pull request reverts the changes introduced by Fix #185 Don't depend on GHC.IO.* from base, from GHC 9.10 #186, because it follows an entirely different route.
• The alternative implementation of withHandleToHANDLE that this pull request introduces is only used when compiling with GHC 9.15 or later.
• It is hoped that the new operations provivded by GHC merge request !14732 will be shipped with GHC 9.16. However, this is not guaranteed, which is why this pull request is marked as a draft at the moment.
• The behavior of the alternative implementation of withHandleToHANDLE differs from the behavior of the traditional implementation in that it blocks operations on the given Haskell handle during the execution of the user-provided action, to an extend that interaction with the Windows handle through the Haskell handle is prevented. It should be checked whether this can cause problems in ansi-terminal. Maybe it will even prevent race conditions.

[mpilgrem]

I have opened issue #190 to correspond to proposed solutions. I suspect I'll have to wait for an alpha of GHC 9.16 before I (a Windows user) can test myself.

EDIT: I have also rebased on master.