Add Windows PID-based kill command --from winuxcmd project

[a-rookie-of-C-language]

Summary

Adds a Windows-specific kill implementation to the multi-call binary.

The new implementation supports PID-based process termination using Windows process APIs. TERM and KILL are accepted for compatibility and both map to Windows process termination.

Fixes #45

Details

• Adds a dedicated src/kill.rs Windows shim.
• Registers kill in the generated utility map.
• Uses OpenProcess(PROCESS_TERMINATE) and TerminateProcess.
• Documents the limited Windows semantics in the README.
• Keeps timeout out of scope.

Validation

• cargo fmt --check
• cargo test --bin coreutils kill::tests
• cargo check --bin coreutils
• git diff --check
• Smoke-tested coreutils.exe kill <pid> against a temporary sleep process.

[a-rookie-of-C-language]

@microsoft-github-policy-service agree

[caomengxuan666]

Nice direction. I checked the GNU coreutils kill semantics, and I think the Windows shim should probably either implement or explicitly document a few gaps:

• kill -0 PID is useful as a non-destructive existence/permission probe.
• kill -l / --list normally supports signal conversion too, e.g. kill -l 9 and kill -l TERM.
• GNU also has -t / --table.
• PID 0 and negative PIDs have process-group semantics on Unix; on Windows we should probably reject those explicitly with a clear "process groups are not supported" message.

TERM/KILL mapping to TerminateProcess makes sense for the Windows-limited behavior, but I think these edge cases should be handled or documented so the command doesn't look more POSIX-compatible than it is.

[a-rookie-of-C-language]

Thank you for your suggestion, I have now added the above support. This is indeed something I had not considered, but it is a very useful command argument. kill -0 PID / kill -s 0 PID: a non-destructive probe, using OpenProcess(PROCESS_TERMINATE) to check if there is permission to open the target process, without calling TerminateProcess.

[caomengxuan666]

Great improvements.

One repo-layout question: most non-uutils commands here seem to live under deps as separate crates/submodules, and then get wired into build.rs / main.rs. Since kill is also a Windows-specific shim, should it live as a small dedicated crate under deps instead of src/kill.rs?

Not sure what layout the maintainers prefer here, but it may be worth deciding before this grows.

[a-rookie-of-C-language]

Good point. I moved the Windows-specific implementation into a small deps/ntkill crate and kept src/main.rs as wiring only. This matches the existing pattern for non-uutils Windows-specific pieces like deps/ntfind, while keeping the kill implementation isolated if it grows later.

[IDisposable]