Unify imports at the top of a file

[ggwpez]

I often see this in some runtime files, where the imports are spread over multiple blocks. The criteria to how these blocks were formed or the logic behind it is not documented and makes it impossible for cargo fmt to remove duplicated or for the developer to find things:

polkadot-sdk/cumulus/parachains/runtimes/assets/asset-hub-rococo/src/lib.rs

Lines 46 to 59 in f6560c2

	create_runtime_str, generic, impl_opaque_keys,
	traits::{AccountIdConversion, AccountIdLookup, BlakeTwo256, Block as BlockT, Verify},
	transaction_validity::{TransactionSource, TransactionValidity},
	ApplyExtrinsicResult, Permill,
	};
	use sp_std::prelude::*;
	#[cfg(feature = "std")]
	use sp_version::NativeVersion;
	use sp_version::RuntimeVersion;
	use codec::{Decode, Encode, MaxEncodedLen};
	use frame_support::{
	construct_runtime,

I think it would be smart to not split the imports with a newline, but have them all in one block.
The only exception would be feature gated imports. As structure i propose:

// Normal imports:
use ...;
use ...;
...

// Feature gated imports:
#[cfg(feature = "std")]
use ::{
    // Std imports all in one block
};

Note that this will cause huge merge conflicts with existing MRs, so please check what MRs are affected first.

[altonen]

On the client side, in some files there is a pattern where crate, external and std imports are in their own blocks. I think that's preferable to clumping everything in one block but since there's no guideline, it's not as consistent as it could perhaps be.

[bkchr]

Yeah, we should come up with some kind of consistent way for doing this and then putting it into the CONTRIBUTING.md. Personally I think moving all to one block or having blocks split in the way @altonen said is fine to me.