Rustdoc bang attr macro

[GuillaumeGomez]

Since it seems like I can't reopen #145458, opening this one. Although, it's the same PR minus the last new commit to handle a comment that was left unresolved in the original PR. All relevant details are still in the original PR though.

It's an alternative (and likely a take-over) of #148005 since lang-team rejected the idea to add documentation on macro branches, making the multiple files approach less suitable.

This implements #145153 in rustdoc. This PR voluntarily doesn't touch anything related to intra-doc links, I'll send a follow-up if needed.

So now about the implementation itself: this is a weird case where a macro can be different things at once but still only gets one file generated. I saw two ways to implement this:

1. Handle ItemKind::Macro differently and iter through its MacroKinds values.
2. Add new placeholder variants in the ItemKind enum, which means that when we encounter them in rendering, we need to ignore them. It also makes the ItemKind enum bigger (and also needs more code to be handled). Another downside is that it needs to be handled in the JSON output.

Now there was an interesting improvement that came with this PR in the html::render::print_item::item_module function: I simplified its implementation and split the different parts in a HashMap where the key is the item type. So then, we can just iterate through the keys and open/close the section at each iteration instead of keeping an Option<section> around.

From RFCs:

• Implement declarative (macro_rules!) attribute macros (RFC 3697) #144579
• Implement declarative (macro_rules!) derive macros (RFC 3698) #145208

r? @notriddle

[rustbot]

Some changes occurred in HTML/CSS/JS.

cc @lolbinarycat

[GuillaumeGomez]

Oh and also cc @lolbinarycat as you reviewed the original PR too. :)

[GuillaumeGomez]

Fixed merge conflicts.

[lolbinarycat]

blocking this on #154902, since that relies on bang macro === macro_rules macro.

[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.