Deprecate and remove the global setuptools.file_finders entry point

[RonnyPfannschmidt]

Context

setuptools-scm registers a setuptools.file_finders entry point that is always active when the package is installed — even for projects that don't use setuptools-scm for versioning. This entry point calls git_find_files() → _git_toplevel(), which runs bare git rev-parse and can walk up to an outer/unrelated git repository.

This was the root cause of #353 (building a non-git package inside an outer git repo), and while the worst symptom (creating a git archive of the wrong repo) is gone, the entry point can still silently return wrong file lists.

Current state

The modern setuptools-scm integration (ScmEggInfoMixin) already bypasses this entry point entirely when a workdir is available: it passes the validated workdir through to list_tracked_files(), which uses --git-dir pinning. So for projects that configure setuptools-scm, the entry point is redundant.

Remaining exposure

The entry point still fires when:

1. setuptools-scm is installed in the build environment but the project being built doesn't configure it
2. The CLI's --query files path calls find_files() directly
3. Any other consumer of walk_revctrl() / setuptools.file_finders

Proposed timeline

1. Next minor release: emit a deprecation warning when the setuptools.file_finders entry point is invoked and no setuptools-scm configuration is found for the project being built
2. Following major release: remove the entry point registration entirely

Alternatives to full removal

• Keep the entry point but add a samefile guard in _git_toplevel so it returns None when the discovered toplevel doesn't match the requested path (prevents the outer-repo walk-up)
• Make the entry point a no-op unless an explicit opt-in is configured

Related: #353