Handle `cfg` blocks in resolve

When there are two items with different cfgs, like

#[cfg(test)]
fn foo() {}

#[cfg(not(test))]
fn foo() {}

#[cfg(unix)]
fn bar() {}

#[cfg(not(unix))]
fn bar() {}

we should pick the non-test one matching the current platform.

This should solve this problem in a principle way. Then this can be extended to fix https://github.com/intellij-rust/intellij-rust/issues/1189.

• support compiler options like unix, target_os, etc - fixed by #4488
• support cargo features:
  • in libraries - fixed by #4635
  • in stdlib
  • in workspace (#4693)
• support cfg_attr (#6497)

[Undin]

@Kobzol I don’t know about any ongoing work on cfg_attr but let’s ask @ortem as well Be careful with org.rust.lang.core.stubs.RsAttributeOwnerStubBase#hasCfg/org.rust.lang.core.stubs.RsAttributeOwnerStubBase#hasMacroUse properties. Currently, our stubs keep info only about direct usages of cfg, macro_use and other code relies on that. But with cfg_attr things become more complex because we can have cfg under cfg_attr (or even under several cfg_attr). Also, it’s impossible to precisely calculate if element has cfg after unfolding all cfg_attrs while stub creation since we have info only about single file. We discussed it with @vlad20012 some time ago and decided that the best solution is to keep only approximate info if an item has cfg/macro_use/etc. attributes in stubs and calculate precise value when needed. Since these properties in stubs were introduced only for performance reasons, it should be ok. For example, the simplest implementation is to return true by the corresponding properties if an element has cfg_attr without any additional unfolding of attributes themselves while stub creation. I don’t know it’s ok or not from performance point of view, it should be investigated.

[nazar-pc]

Here is another one that is currently not handled nicely:

#[cfg(not(doc))]
pub use router::consumer;
#[cfg(doc)]
#[path = "router/consumer.rs"]
pub mod consumer;

I’m doing this because of https://github.com/rust-lang/rust/issues/59368, but now IDE is confused and thinks those are 2 modules and doesn’t know which one to use, so uses neither.