Prefer using Distribution.has_ext_modules method

[messense]

This would allow downstream packages like setuptools-rust to tell setuptools that the distribution has ext_modules, see https://github.com/PyO3/setuptools-rust/blob/75787159051f133f24dbceeb143ee5ae976c7244/setuptools_rust/setuptools_ext.py#L226-L229

Fixes PyO3/setuptools-rust#146

[jaraco]

I can see how this change addresses the issue. It allows a plugin or customized build to hack the distribution to change the meaning of has_ext_modules to return True even when .ext_modules is empty or None.

The problem with this change is that it creates an implicit contract allowing for the above behavior. This change could get optimized away and there's nothing to prevent it... and Rust users would find their builds broken again and blame the change. At the same time, I'm disinclined to suggest that this project should have a test to capture the expectation that a plugin might monkey-patch has_ext_modules.

While I'm okay to accept this change to unblock Rust build issues, I'd really like to see (longer term) some effort to support all extension modules regardless of language with a consistent interface (i.e. such that .ext_modules contains the Rust extension modules) and so that build.finalize_options or dist.has_ext_modules doesn't need to be hacked to support them, or has_ext_modules can be removed entirely and replaced by simply .ext_modules.

Please feel encouraged to spearhead an effort to help distutils/Setuptools have native, integrated support for extension modules in Rust and other languages.