Implement `//@ target` directive for cross-compilation test directives

[jchecahi]

Currently, compiletest directives like needs-asm-support, needs-unwind, and others check properties of the host architecture rather than the target architecture. This creates issues for cross-compilation tests that use --target flags, as they may be incorrectly skipped or executed based on host capabilities rather than the capabilities of the target being tested.

Background

This issue arose from the discussion in #147406, where needs-asm-support was being removed from tests that explicitly cross-compile to specific targets. The directive was checking host asm support and causing tests to be skipped on hosts like ppc64le (which doesn't have stable asm support), even when testing targets like s390x or x86_64 (which do support asm).

As noted by @cuviper in that PR: for in-tree compiler tests, if someone wrote a target-specific asm test, that target obviously supports asm.

Suggestion from PR Discussion

During the review of PR #147406, @bjorn3 and @workingjubilee suggested implementing a //@ target <triple> directive as a more comprehensive solution to the host-vs-target confusion in compiletest directives.

The idea, as I understand it from the discussion, would be to create a directive that automatically handles test requirements based on the target architecture. This could potentially:

1. Automatically determine required LLVM components (eliminating manual needs-llvm-components)
2. Check target capabilities (asm support, unwind support, etc.) based on the target, not the host
3. Set the compilation target (replacing or supplementing --target in compile-flags)
4. Default to the host target when not specified (maintaining current behavior)

If feasible, this could make cross-compilation tests simpler and less error-prone, as the test infrastructure would automatically know what's needed based on the target triple. Having a target directive makes it very clear that the test is cross-compiled as well.

[jieyouxu]

Note: we need to clean up the directive handling in compiletest first before introducing more complex directive handling like this.

@rustbot label: -needs-triage +S-blocked +T-bootstrap +C-enhancement