include .pyw files by default when linting and formatting

[amyreese]

• Adds test cases exercising file selection by extension with --preview enabled and disabled.
• Adds INCLUDE_PREVIEW with file patterns including *.pyw.
• In global preview mode, default configuration selects patterns from INCLUDE_PREVIEW.
• Manually tested ruff server with local vscode for both formatting and linting of a .pyw file.

Closes #13246

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

[MichaReiser]

The basics here look good, but there are a few more places we have to account for pyw files.

One such place is PySourceType. It's heavily used internally to query whether a file is a Python file, a stub file, or a notebook. We need to decide if we need to add a new variant or if it's okay to add pyw to py (might not be okay if PySourceType is used in any module resolution logic as pyw files aren't importable as far as I know). This will require reviewing where PySourceType is used (and how).

It might also be good to do a quick search for ".py" (or "pyi" because there are fewer instances) to see if there are other places where we check for the extension that need updating.

This is related to #13691

[amyreese]

One such place is PySourceType. It's heavily used internally to query whether a file is a Python file, a stub file, or a notebook. We need to decide if we need to add a new variant or if it's okay to add pyw to py (might not be okay if PySourceType is used in any module resolution logic as pyw files aren't importable as far as I know). This will require reviewing where PySourceType is used (and how).

I tried looking through various places where this is used, but there really is an overwhelming number of places where it's used that I don't have context on, but what I've looked at so far usually seems reasonable.

I went ahead and added the mapping to the existing Python enum, and tests are passing, but I don't have a good idea what sort of tests I could add to help give signal on whether that is sufficient, or how to compare that with the alternative of adding a new enum type.

That said, I'm also not sure what you mean by "module resolution logic", so if you can suggest specific crates/files to look at more closely, I'd be happy to dig further.

It might also be good to do a quick search for ".py" (or "pyi" because there are fewer instances) to see if there are other places where we check for the extension that need updating.

I did do that originally, though I searched for ipynb instead, but apparently I missed the exact one place that PySourceType showed up in the gigantic list of results. 😅🫠

[MichaReiser]

I tried looking through various places where this is used, but there really is an overwhelming number of places where it's used that I don't have context on,

Yeah, same here. We don't need to study each line for a very long time. It's okay if we miss something.

I only did a quick search. Most usages indeed do look good. The one I think we need to take a closer look is

ruff/crates/ruff_linter/src/rules/flake8_no_pep420/rules/implicit_namespace_package.rs

Lines 72 to 73 in b027926

	// Ignore non-`.py` files, which don't require an `__init__.py`.
	&& PySourceType::try_from_path(path).is_some_and(PySourceType::is_py_file)

because it tries to resemble python's module resolution at runtime.