feat: Integrate wheel repairer

[LecrisUT]

The goal of this is:

• Get the linked libraries from the configure step
• Check if the paths start with the current build environment's sysconfig.get_path("platlib")
  (pip fake venv is really annoying here)
• If so patch the RPATH to be relative paths
• Patch existing RPATHs of the current wheel files, e.g. from CMAKE_INSTALL_RPATH_USE_LINK_PATH
• For windows systems, add dlls to Scripts path.
  Maybe would be better to use the existing paths instead.
• Do some other magic that delvewheel does
  Afaict, the only special thing it does is inject os.add_dll_directory. Cannot support subprocess.run right now, but we could do it if we generate the wrappers. Will make a subsequent PR for that.

To discuss:

• Should this be separated as a standalone plugin and instead expose an entry-point scikit-build.repair-wheel?
• Initially I was considering using auditwheel/delocate/delvewheel directly, but these do not handle differently the packages in site-package vs external
• Do we extend the interface to pick up system packages as well? I was thinking that the repairwheel trio can do all the hard work generally, but maybe the user needs more nuanced configuration, e.g. with Qt/PySide the requirement is to bundle the Qt framework uniquely, compared to dlevewheel which creates separate dlls for each wheel.

Depends-on: #1022 #1016

[LecrisUT]

Ready for review for this initial proposal. Further proposals that I want to build up from this

• Expand the wheel.repair to accept more complex repairs
• Make the repair-wheel plugin-able, allowing to specify either a script (PEP723 looks really nice for this) or a entry-point, to allow more fine-grained repairs
• Add an option to bundle a glob list of libraries