fix(clean): Respect --target when no package is specified

[isHeSatoshi]

What does this PR try to resolve?

Fixes #17311.

Without -p, cargo clean removed the whole target directory, so --target was accepted
and then ignored:

$ cargo build --target host-tuple   # writes target/<host>/
$ cargo clean --target host-tuple   # removes the entire target directory

cargo clean --doc --target (fixed in #17310) and cargo clean -p --target both respect
--target already, so this makes the remaining case behave the same way, matching what the
--target documentation says: "Clean for the specified target architecture."

How to test and review this PR?

The directories to remove are now computed as
<target-dir>[/<triple>][/<profile-dir>], the same way Layout nests them, since the
profile directory lives inside the target one and so can no longer be appended up front.

Without --target the same directories as before are removed. In particular the scoping is
driven by the command-line --target alone, so a build.target in the config does not turn
cargo clean into a per-target clean.

With two targets and two profiles present in the target directory:

$ cargo clean --release --target host-tuple
     Removed 2 directories
$ ls target
CACHEDIR.TAG  debug  .rustc_info.json  x86_64-pc-windows-msvc

tests/testsuite/clean.rs adds clean_target, which checks that only target/<triple> is
removed (and with --release --target only its release directory), while the host output
survives. The existing tests cover --profile without --target and a plain cargo clean.

Verified with:

$ cargo test --test testsuite -- clean
test result: ok. 112 passed; 0 failed; 4 ignored; 0 measured; 4303 filtered out; finished in 16.35s

$ cargo fmt --check
(no output)

---

🤖 LLM disclosure: This PR - the code change, the tests and this description - was produced by
an LLM agent on the author's behalf, then built and tested as described above. Flagging it per
the LLM usage policy so reviewers can
decide whether to take it on. Happy to answer questions, or to close it, if that is preferred.

[rustbot]

Thanks for the pull request, and welcome! The Rust Project has assigned @weihanglo (or someone else) to review your changes, you should hear from them (or someone else) within the next two weeks.

Please see the contribution instructions and our LLM policy for more information.

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @Muscraft, @epage, @weihanglo
• @Muscraft, @epage, @weihanglo expanded to Muscraft, epage, weihanglo
• Random selection from Muscraft, epage, weihanglo

[Muscraft]

🤖 LLM disclosure: This PR - the code change, the tests and this description - was produced by an LLM agent on the author's behalf, then built and tested as described above. Flagging it per the LLM usage policy so reviewers can decide whether to take it on. Happy to answer questions, or to close it, if that is preferred.

I am going to have to close this PR as our LLM policy states that LLM-created code changes require a reviewer to be pre-arranged.

One other thing to note is that #17311 was not marked as S-accepted. Issues should be marked with S-accepted before a PR is opened.