Honor an explicit stop signal on container stop

[shuaiyuanxx]

What this PR does / why we need it:

podman ignored the signal for a graceful stop: the compat /stop endpoint dropped the signal query parameter, podman stop had no --signal flag, and the OCI runtime always used the container's configured StopSignal. Docker has supported
stop --signal (and the API signal parameter) since v1.42, so there was no way to stop a container with an override signal.

This threads an optional stop signal from the CLI (--signal/-s), the remote bindings, and the compat/libpod /stop endpoint down to the OCI runtime, which uses the override when given (0 = the configured StopSignal) and still escalates to SIGKILL after the timeout. Internal stop paths pass 0, so behavior is unchanged when no signal is requested.

How to verify it

    podman run -d --name s alpine sh -c 'trap "exit 42" USR1; while :; do sleep 0.1; done'
    podman stop --signal SIGUSR1 -t 20 s
    podman inspect s --format '{{.State.ExitCode}}'   # 42 = SIGUSR1 delivered (not the default)

New e2e test: podman stop container --signal.

Which issue(s) this PR fixes:

None

Checklist

• Certify ... by signing all commits (git commit -s).
• Referenced issues using Fixes: #issue (if applicable) — no related issue
• Tests have been added/updated
• Documentation has been updated (podman-stop.1.md.in)
• All commits pass make validatepr — ran gofmt + go vet ./test/e2e + binary build + a runtime check; haven't run the full validatepr
• Release note entered below

Does this PR introduce a user-facing change?

Added a `--signal`/`-s` option to `podman stop` and honored the `signal` query parameter on the stop API, so a container can be stopped with an explicit signal instead of its configured stop signal.