Add exclude-exts options

[oraluben]

This PR adds an exclude-exts option to wheel config.

Why not use existing exclude?

1. Previously .pyc and .pyo were hard-coded to be excluded and there was no way to configure this
2. Pattern-based exclusion for file extensions is not always straightforward (e.g., using **/*.c* to exclude *.c, *.cpp, *.cu* would accidentally exclude compiled *.cpython*.so files)

[LecrisUT]

Please add a :::{versionadded} 0.12 in here and any other sphinx relevant parts you see fit.

[LecrisUT]

Suggested change

	default_factory=lambda: [".pyc", ".pyo"],
	metadata=SettingsFieldMetadata(display_default="true"),
	default=[".pyc", ".pyo"],

display_default will show that literal text in the documentation, I believe you don't want it to display true there right? Also, the lambda is unnecessary.

[LecrisUT]

I wonder why we have defaults for these. But anyway it's an existing pattern.

[LecrisUT]

I don't think the format looks right here, can you rearrange it? https://scikit-build-core--1128.org.readthedocs.build/en/1128/configuration/index.html#customizing-the-built-wheel

Also, this is new since the introduction of Config Reference, but can you use :confval:... role to reference the new option? There's a nice pop-up of the information about it, so you could de-duplicate some documentation with that.

[henryiii]

Could you explain why you need it? It's incorrect to place a .pyc file into a wheel; as an example, the magic number just changed between 3.14rc1 and 3.14rc2, and it's considered fine because .pyc's aren't part of wheels. And your example of how **/*.c* doesn't work doesn't make much sense when the replacement doesn't support globbing; so you'd have to do [".c", ".cpp"], but then ["*.c", "*.cpp"] would also have been safe.

I'm about to rework file inclusion/exclusion to support several modes, and this might be a good addition to that, but I'd like to start that work and see how it fits in before making a final decision. :)

[LecrisUT]

We probably would always inject the [".pyc", ".pyo"], but to have an extension-based way to filter does seem easier to manage without accidental footguns. From the example given by OP, I can see bullet shaped hole in the foot 😉