Judge an explicitly-named file by the same rules as a file found in a directory

[Eljees]

Description

The same file gets a different answer depending on how it was named on the command line:

file	found by walking a directory	named directly
a.ipynb, run with --ext ipynb	interrogated	E: Invalid file …, exit code 1
a.pyi, no --ext	skipped	interrogated

_filter_files() (used for a directory walk) matches against self.extensions, so it honours --ext. get_filenames_from_paths() matches an explicitly-named file against the hard-coded VALID_EXT instead, so --ext is ignored there and the run aborts with sys.exit(1).

This change gives the explicit path the union of VALID_EXT and the --ext values (a union, so a .pyi file named directly keeps working without --ext), and additionally accepts a file that has no extension when its first line is a Python shebang. Files that do have an extension are never sniffed, so script.sh is not picked up because of its contents. The directory walk is untouched — I did not want interrogate reading the first bytes of every file in a tree.

Motivation and Context

Fixes #104, which reports the shebang half: interrogate bin/postgres-ready refuses a #!/usr/bin/env python script because the name lacks .py, even though identify-cli and file(1) both call it Python.

The --ext half showed up while reproducing it, and it seems the more clear-cut of the two: the 1.7.0 changelog promises "Support for pyi file extensions (and leave room for other file extensions to be added, like maybe ipynb)", and that promise currently holds for one of the two code paths only.

Have you tested this? If so, how?

I have included unit tests, and I ran interrogate on the reporter's exact command before and after.

• tests/functional/test_issue_104.py has four cases: .ipynb named directly with --ext ipynb and an extension-less shebang script both fail on master (SystemExit: 1) and pass with this change; the same .ipynb found via a directory walk, and a README with neither a shebang nor an extension (still rejected), are controls that pass either way.
• Full suite: 228 passed on master, 232 passed with this change, no failures either way. (With tabulate 0.10.0, five test_print_results* tests fail on plain master too — that is Support (and require) tabulate version 0.10.0 #189, unrelated to this change.)
• interrogate -vv bin/postgres-ready now prints the coverage table and exits 1 because of genuinely missing docstrings, rather than refusing the file.

Checklist for PR author(s)

• Changes are covered by unit tests (no major decrease in code coverage %).
• All tests pass.
• Docstring coverage is 100% via tox -e docs or interrogate -c pyproject.toml (I mean, we should set a good example 😄).
• Updates to documentation:
  • Document any relevant additions/changes in README.rst. (No flag changed; --ext simply now behaves as documented. Happy to add a sentence if you would like one.)
  • Manually update both the README.rst and docs/index.rst for any new/changed CLI flags. (No CLI flags added or changed.)
  • Any changed/added classes/methods/functions have appropriate versionadded, versionchanged, or deprecated directives. (Both new methods are private and carry .. versionadded:: 1.8.0.)

Release note

Accept an explicitly-named file whose extension was given with ``--ext``, or which has no extension but starts with a Python shebang.