Add Shell method for running commands via the system shell

[Dhanalakshmi-D04]

Adds a new Shell method (and package-level Shell function) that runs
a command line through the operating system's native shell, rather than
manually parsing arguments the way Exec does. This fixes the
WithEnv/variable-expansion bug described in #239, while leaving Exec
itself unchanged for backward compatibility, per the discussion on the
issue.

--Implementation

• Unix-like systems: the command line is passed to sh -c unmodified,
  so $VAR-style expansion, quoting, and other shell syntax are handled
  by the real shell.
• Windows: the command line is passed to cmd /C, following the
  direction suggested in the issue ("give the command line to CMD.exe
  so that it's processed in the same way that it would be if the user
  had typed it into a terminal"). Note that Windows uses %VAR% syntax
  rather than $VAR, since that's native to cmd.exe.
• The platform-specific command construction lives in shell_unix.go
  and shell_windows.go, using the same //go:build pattern already
  used for script_unix_test.go / script_windows_test.go.

--Testing

• Unix implementation tested on Fedora Linux — all tests pass, including
  a test confirming WithEnv variables are now correctly expanded
  (TestShell_ExpandsEnvironmentVariablesSetViaWithEnv), directly
  verifying the fix for the original bug.
• Windows implementation tested on Windows 11 (PowerShell) — all tests
  pass, including the Windows equivalent using %VAR% syntax.
• Full existing test suite (go test ./...) passes on both platforms
  with no regressions.

--Docs

• Added doc comments for Shell (package function and method).
• Updated the README's Sources and Filters tables.

I couldn't find a doMethodsOnPipe stress-test helper mentioned in
CONTRIBUTING.md anywhere in the current codebase — let me know if it's
been renamed or removed, and I'll update accordingly.

Happy to adjust naming, structure, or behavior based on feedback.

[bitfield]

I couldn't find a doMethodsOnPipe stress-test helper mentioned in
CONTRIBUTING.md

Good spotting—that's out of date. I'll update the contributing guide.

[bitfield]

Is it possible to implement this in terms of Exec? That would mean we don't have to repeat all the command-setup code and keep these two methods in sync. For example, I recently merged #244, so Exec now uses a context if there is one on the pipe. If you used Exec to write Shell, you wouldn't have to do anything special to pick up that change; you'd get it for free.

[Dhanalakshmi-D04]

Good point on the duplication — that makes sense, especially with the context support in #244 that Shell would otherwise miss out on. I'll refactor so Shell builds on Exec's command-setup logic instead of duplicating it, and update the PR shortly.

[Dhanalakshmi-D04]

Done — extracted the shared command-running logic (stdin/stdout/stderr, WithEnv, start/wait, error handling) into an unexported runCmd helper used by both Exec and Shell. Shell now also uses exec.CommandContext, so it picks up context support from #244 automatically. Verified with go build, go vet, and the full test suite on both Linux and Windows — all clean. Pushed as a separate commit so the diff is easy to follow alongside the original.