[clang] [llvm] [libclang/python] Enable packaging libclang bindings (PR #125806)

[Ryan Mast via llvm-commits]

nightlark wrote:

For reviewers, here's a summary of the potential issues that come to mind and what has been done to verify things are working as expected:

* The packaging metadata (keywords, name, author/contact info, etc) don't match what we expect
    - check the pyproject.toml and make sure the classifiers, keywords, etc look okay
* The source distribution and wheel files built (using `python -m build`) have more files than necessary (these are the things that would be uploaded to PyPI and actually installed by users)
    - checked by cloning the LLVM repo and then from the folder with pyproject.toml, building the sdist and wheel (placed in `dist` subfolder by default); unzip the *.whl file, and uncompress the *.tar.gz file to see what files they have in them
    - after creating a fake `llvmorg-19.2.3` tag in my forked repo and doing the above, I got these two files: [clang-19.2.3-py3-none-any.whl.zip](https://github.com/user-attachments/files/19093083/clang-19.2.3-py3-none-any.whl.zip)(note extra layer of zipping to attach to GitHub comment) [clang-19.2.3.tar.gz](https://github.com/user-attachments/files/19093084/clang-19.2.3.tar.gz)
    - the sdist and wheel files can also be pip installed: `pip install clang-19.2.3.tar.gz` or `pip install clang-19.2.3-py3-none-any.whl`
* The python bindings aren't placed in the right folder to import them when the package is pip installed
    - verified by pip installing the built wheel and then in Python `import clang.cindex`
* The version number detected when building a wheel for tagged releases isn't correct
    - verified by tagging a fake release, and then building the sdist+wheel as mentioned above and make sure the file names have the right version number in them (this is key one for the CI workflow that will release files that users get)
    - version numbers picked up on the main branch will just be the major version number (taken from the `llvmorg-N-init` tag) and likely have a development version component (e.g. clang-21.post1.dev678+g42108e2298cc.tar.gz); only developers working on LLVM will ever install the package in this way and see versions like this
* Installing directly from a git URL or source archives for a release won't work
    - for the git URL install with: `pip install git+https://github.com/nightlark/llvm-project@add-python-packaging#subdirectory=clang/bindings/python`
    - for the source archive: `pip install https://github.com/nightlark/llvm-project/archive/refs/heads/add-python-packaging.zip#subdirectory=clang/bindings/python`
    - end users of the clang Python bindings will be installing from the published PyPI package, so these methods of installation will be rarely used

In practice, the things affecting users will be issues related to the sdist and wheel files built for a specific tagged commit and the other installation methods working fit more into the category of nice-to-haves for LLVM devs.

https://github.com/llvm/llvm-project/pull/125806