Add -Zstack-protector-guard target modifier

[alvinsun039]

Add a new unstable -Z stack-protector-guard target modifier to
configure how the stack canary is accessed, equivalent to Clang's
-mstack-protector-guard=* options.

Usage: -Z stack-protector-guard=<mode>[,offset=N][,reg=R][,symbol=S]

This is needed by Rust-for-Linux to support per-task stack canary
(CONFIG_STACKPROTECTOR_PER_TASK), where the canary is stored in a
per-task location rather than a global __stack_chk_guard variable.

MCP: rust-lang/compiler-team#1013
Zulip: https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/-Z.20stack-protector-guard.20flags

[rustbot]

Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @chenyukang (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 75 candidates
• Random selection from 16 candidates

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[chenyukang]

@rustbot reroll

[rust-bors]

☔ The latest upstream changes (presumably #160284) made this pull request unmergeable. Please resolve the merge conflicts by rebasing.

[JohnTitor]

@rustbot reroll

[TaKO8Ki]

Waiting for the MCP to be accepted.

@rustbot blocked