Unify rustc and rustdoc parsing of cfg()

[jyn514]

This extracts a new parse_cfg function that's used between both.

• Treat #[doc(cfg(x), cfg(y))] the same as #[doc(cfg(x)] #[doc(cfg(y))]. Previously it would be completely ignored.
• Treat #[doc(inline, cfg(x))] the same as #[doc(inline)] #[doc(cfg(x))]. Previously, the cfg would be ignored.
• Pass the cfg predicate through to rustc_expand to be validated

Technically this is a breaking change, but doc_cfg is still nightly so I don't think it matters.

Fixes #84437.

r? @petrochenkov

[jyn514]

cc @Nemo157

[petrochenkov]

FWIW, there's one more place with similar logic - fn parse_cfgspecs, not sure whether some code can be shared with it or not.

[jyn514]

FWIW, there's one more place with similar logic - fn parse_cfgspecs, not sure whether some code can be shared with it or not.

I don't think so - it only allows idents, not full lists:

                        match &meta_item.kind {
                            MetaItemKind::List(..) => {
                                error!(r#"expected `key` or `key="value"`"#);
                            }
                            MetaItemKind::NameValue(lit) if !lit.kind.is_str() => {
                                error!("argument value must be a string");
                            }
                            MetaItemKind::NameValue(..) | MetaItemKind::Word => {
                                let ident = meta_item.ident().expect("multi-segment cfg key");
                                return (ident.name, meta_item.value_str());
                            }
                        }

and at that point it's only a few lines anyway.

[jyn514]

Ok, this is ready for review.

[jyn514]

cc @Nemo157 since this now allows #[doc(cfg(x), cfg(y))] (but we already chatted and he's fine with it).