Unify the styling of dependencies in Cargo.toml

[liuchengxu]

Basically, my personal taste for the dependencies styling, the main idea is : non-substrate deps, sc-*, sp-*, frame-*/pallet-*, subspace deps. Feel free to suggest another one, but a unified style is always good for collaboration.

Putting the dep items in batches also brings more convenience for the batch editing operation in a text editor.

No code changes, only styling stuff. I believe it works if it compiles.

Related #44.

[nazar-pc]

General comments:

• No need to split dependencies into multiple sections and prefix with # Subspace, one list sorted alphabetically is fine
• [dependencies.X] is actually preferred for non-trivial dependencies in crates that are not inherently related to Substrate
  • One reason Substrate-related crates are different is because we inherited code style from there
  • Second and more important reason is that the number of dependencies in those is insane and expanded form will not be much more readable either, probably even worse
  • I usually use compact form for simple dependencies and expanded for those that need thigns customized, because sometimes we need to do not pretty things like https://github.com/subspace/subspace/blob/5ec95d5120ae07234952270984cf4407157a0c41/crates/subspace-archiving/Cargo.toml#L25-L44
• Please don't change crate authors (code is licensed by the company, but authored by individuals)

[liuchengxu]

The benefit for multiple sections is that we can separate out the client-only and runtime-related crates clearly, runtime means it should compile under no_std and we could spot the missing no_std feature easier aside from relying on the compiler :D.

I agree that [dependencies.X] is more suitable for complex cases, but I think we should stick with one style for the common simple cases.

[nazar-pc]

we can separate out the client-only and runtime-related crates clearly

I don't see much benefit in that, it is pretty clear that if you have something under runtime or deeper in dependencies, it should be no_std-compatible or else it doesn't compile, in all other cases it no_std has no relevance, so it is not much of a problem. I would prefer to stick to a simpler rule with a single section and alphabetically sorted dependencies.

What do you think about using https://github.com/dprint/dprint in CI and automate the process of maintaining the formatting of Cargo.toml files?

[liuchengxu]

Well, for me, the multiple sections(e.g., Subspace section) allow me to know which crates are not using the upstream directly but written on our own at the first glance, but I'm ok if you insist that only one section is enough.

I don't have a strong opinion on dprint as toml seemingly does not have an official formatter like rustfmt. It's good to me as long as it helps us achieve a sort of consistent style that is acceptable to all of us.

[nazar-pc]

Yes, let's use a single section for now and this should be good to go.

dprint was suggested in rust-lang/rustfmt#4091, not critical for now

[nazar-pc]

Node dependencies still have multiple sections, looks good otherwise

[nazar-pc]

Thank you!