fix: Better import placement + merging

[tascord]

fix stuff relating to imports.

1. #[cfg]'s act as hard barriers for import globbing

   use { /* ...*/ };
   
   #[cfg(target_arch = "x86_64")]
   pub mod api;
   // 🡴 The cfg'd mod here causes RA to no longer see the use above. Quick-action imports will be added to a NEW use block here, rather than at the top of the file.

2. #[cfg] attribute ordering matters (was a FIXME)

   #[cfg(a)] #[cfg(b)] use foo;
   #[cfg(b)] #[cfg(a)] use bar; // RA wouldn't merge these before

3. If an existing #[cfg] use block exists, RA will still prefer to create a new import block instead of merging, when in #[cfg]'d functions. (Import insertion on signature for cfg attributed function puts import into the function #9391)

   #[cfg(target_os = "linux")]
   use existing::Item;
   
   #[cfg(target_os = "linux")]
   fn main() {
       // Auto-importing `NewItem` here would previously create a local import
   }

[tascord]

@Billy-Sheppard am i missing anything in this one?

[Billy-Sheppard]

Does it solve this issue here?

    // `x`
    use foo::Foo; 

    #[cfg(target_arch = "x86_64")] // `y`
    use bar::Baz;

When I auto-import within a #[cfg(target_arch = "x86_64")] scope, I want it to go into the y import block when using imports_granularity = "One".
Not into:

    #[cfg(target_arch = "x86_64")]
    fn buzz() {
        use buzz::Buzz;
    }

To make something like

    // `x`
    use foo::Foo; 

    #[cfg(target_arch = "x86_64")] // `y`
    use {
        bar::Baz,
        buzz::Buzz,
    };

[JLesDev]

LGTM 🚀

[ShoyuVanilla]

Looks great overall 👍

2. #[cfg] attribute ordering matters (was a FIXME)

    #[cfg(a)] #[cfg(b)] use foo;
    #[cfg(b)] #[cfg(a)] use bar; // RA wouldn't merge these before

Could you add a test for this case as well?

[ShoyuVanilla]

Thanks!