Rollup merge of #144080 - jieyouxu:realign, r=BoxyUwU

Mitigate `#[align]` name resolution ambiguity regression with a rename

Mitigates beta regression #143834 after a beta backport.

### Background on the beta regression

The name resolution regression arises due to #142507 adding a new feature-gated built-in attribute named `#[align]`. However, unfortunately even [introducing new feature-gated unstable built-in attributes can break user code](https://www.github.com/rust-lang/rust/issues/134963) such as

```rs
macro_rules! align {
    () => {
        /* .. */
    };
}

pub(crate) use align; // `use` here becomes ambiguous
```

### Mitigation approach

This PR renames `#[align]` to `#[rustc_align]` to mitigate the beta regression by:

1. Undoing the introduction of a new built-in attribute with a common name, i.e. `#[align]`.
2. Renaming `#[align]` to `#[rustc_align]`. The renamed attribute being `rustc_align` will not introduce new stable breakages, as attributes beginning with `rustc` are reserved and perma-unstable. This does mean existing nightly code using `fn_align` feature will additionally need to specify `#![feature(rustc_attrs)]`.

This PR is very much a short-term mitigation to alleviate time pressure from having to fully fix the current limitation of inevitable name resolution regressions that would arise from adding any built-in attributes. Long-term solutions are discussed in [#t-lang > namespacing macro attrs to reduce conflicts with new adds](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/namespacing.20macro.20attrs.20to.20reduce.20conflicts.20with.20new.20adds/with/529249622).

### Alternative mitigation options

[Various mitigation options were considered during the compiler triage meeting](#143834 (comment)), and those consideration are partly reproduced here:

- Reverting the PR doesn't seem very minimal/trivial, and carries risks of its own.
- Rename to a less-common but aim-to-stabilization name is itself not safe nor convenient, because (1) that risks introducing new regressions (i.e. ambiguity against the new name), and (2) lang would have to FCP the new name hastily for the mitigation to land timely and have a chance to be backported. This also makes the path towards stabilization annoying.
- Rename the attribute to a rustc attribute, which will be perma-unstable and does not cause new ambiguities in stable code.
    - This alleviates the time pressure to address *this* regression, or for lang to have to rush an FCP for some new name that can still break user code.
    - This avoids backing out a whole implementation.

### Review advice

This PR is best reviewed commit-by-commit.

- Commit 1 adds a test `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` which demonstrates the current name resolution regression re. `align`. This test fails against current master.
- Commit 2 carries out the renames and test reblesses. Notably, commit 2 will cause `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` to change from fail (nameres regression) to pass.

This PR, if the approach still seems acceptable, will need a beta-backport to address the beta regression.

[beta] backports

- Reword mismatched-lifetime-syntaxes text based on feedback #143914
- Fix `-Ctarget-feature`s getting ignored after `crt-static` #144143
- Mitigate `#[align]` name resolution ambiguity regression with a rename #144080

r? cuviper

Mitigate `#[align]` name resolution ambiguity regression with a rename

Mitigates beta regression rust-lang#143834 after a beta backport.

### Background on the beta regression

The name resolution regression arises due to rust-lang#142507 adding a new feature-gated built-in attribute named `#[align]`. However, unfortunately even [introducing new feature-gated unstable built-in attributes can break user code](https://www.github.com/rust-lang/rust/issues/134963) such as

```rs
macro_rules! align {
    () => {
        /* .. */
    };
}

pub(crate) use align; // `use` here becomes ambiguous
```

### Mitigation approach

This PR renames `#[align]` to `#[rustc_align]` to mitigate the beta regression by:

1. Undoing the introduction of a new built-in attribute with a common name, i.e. `#[align]`.
2. Renaming `#[align]` to `#[rustc_align]`. The renamed attribute being `rustc_align` will not introduce new stable breakages, as attributes beginning with `rustc` are reserved and perma-unstable. This does mean existing nightly code using `fn_align` feature will additionally need to specify `#![feature(rustc_attrs)]`.

This PR is very much a short-term mitigation to alleviate time pressure from having to fully fix the current limitation of inevitable name resolution regressions that would arise from adding any built-in attributes. Long-term solutions are discussed in [#t-lang > namespacing macro attrs to reduce conflicts with new adds](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/namespacing.20macro.20attrs.20to.20reduce.20conflicts.20with.20new.20adds/with/529249622).

### Alternative mitigation options

[Various mitigation options were considered during the compiler triage meeting](rust-lang#143834 (comment)), and those consideration are partly reproduced here:

- Reverting the PR doesn't seem very minimal/trivial, and carries risks of its own.
- Rename to a less-common but aim-to-stabilization name is itself not safe nor convenient, because (1) that risks introducing new regressions (i.e. ambiguity against the new name), and (2) lang would have to FCP the new name hastily for the mitigation to land timely and have a chance to be backported. This also makes the path towards stabilization annoying.
- Rename the attribute to a rustc attribute, which will be perma-unstable and does not cause new ambiguities in stable code.
    - This alleviates the time pressure to address *this* regression, or for lang to have to rush an FCP for some new name that can still break user code.
    - This avoids backing out a whole implementation.

### Review advice

This PR is best reviewed commit-by-commit.

- Commit 1 adds a test `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` which demonstrates the current name resolution regression re. `align`. This test fails against current master.
- Commit 2 carries out the renames and test reblesses. Notably, commit 2 will cause `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` to change from fail (nameres regression) to pass.

This PR, if the approach still seems acceptable, will need a beta-backport to address the beta regression.

Mitigate `#[align]` name resolution ambiguity regression with a rename

Mitigates beta regression rust-lang#143834 after a beta backport.

### Background on the beta regression

The name resolution regression arises due to rust-lang#142507 adding a new feature-gated built-in attribute named `#[align]`. However, unfortunately even [introducing new feature-gated unstable built-in attributes can break user code](https://www.github.com/rust-lang/rust/issues/134963) such as

```rs
macro_rules! align {
    () => {
        /* .. */
    };
}

pub(crate) use align; // `use` here becomes ambiguous
```

### Mitigation approach

This PR renames `#[align]` to `#[rustc_align]` to mitigate the beta regression by:

1. Undoing the introduction of a new built-in attribute with a common name, i.e. `#[align]`.
2. Renaming `#[align]` to `#[rustc_align]`. The renamed attribute being `rustc_align` will not introduce new stable breakages, as attributes beginning with `rustc` are reserved and perma-unstable. This does mean existing nightly code using `fn_align` feature will additionally need to specify `#![feature(rustc_attrs)]`.

This PR is very much a short-term mitigation to alleviate time pressure from having to fully fix the current limitation of inevitable name resolution regressions that would arise from adding any built-in attributes. Long-term solutions are discussed in [#t-lang > namespacing macro attrs to reduce conflicts with new adds](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/namespacing.20macro.20attrs.20to.20reduce.20conflicts.20with.20new.20adds/with/529249622).

### Alternative mitigation options

[Various mitigation options were considered during the compiler triage meeting](rust-lang#143834 (comment)), and those consideration are partly reproduced here:

- Reverting the PR doesn't seem very minimal/trivial, and carries risks of its own.
- Rename to a less-common but aim-to-stabilization name is itself not safe nor convenient, because (1) that risks introducing new regressions (i.e. ambiguity against the new name), and (2) lang would have to FCP the new name hastily for the mitigation to land timely and have a chance to be backported. This also makes the path towards stabilization annoying.
- Rename the attribute to a rustc attribute, which will be perma-unstable and does not cause new ambiguities in stable code.
    - This alleviates the time pressure to address *this* regression, or for lang to have to rush an FCP for some new name that can still break user code.
    - This avoids backing out a whole implementation.

### Review advice

This PR is best reviewed commit-by-commit.

- Commit 1 adds a test `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` which demonstrates the current name resolution regression re. `align`. This test fails against current master.
- Commit 2 carries out the renames and test reblesses. Notably, commit 2 will cause `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` to change from fail (nameres regression) to pass.

This PR, if the approach still seems acceptable, will need a beta-backport to address the beta regression.