chore: Add rustfmt.toml with some unstable format options

[sbernauer]

Fixup of #136
Back in the day I put it in the wrong folder 🤦‍♂️ We already have this in secret-op for ~2 years now.

The amount of time I have seen suggestions regarding merging imports and sorting (std, external, crate), I'm very happy that we can solve all of that by automation 🥳

cargo +stable fmt currently gives a warning, but still returns exit code 0 (so can be ignored)
Use cargo fmt to run the formatting.

See #136

For what it's worth, you can run a single cargo command using the nightly toolchain by using cargo +nightly fmt.

Rust-Analyzer should also allow you to set rustfmt-specific flags (for Emacs, put (setq rust-rustfmt-switches '("+nightly" "--edition" "2018")) into your .emacs), and I assume Rust-IntelliJ has something similar.

[sbernauer]

@siegfriedweber had a good point that this might result in back and forth changes between developer machines with different nightly versions.
We could pin a specific nightly version, but that implies some maintenance burden.

As kube is also using a nightly formatter I would like to give it a try and see if that is really the case. In that case we should be able to pin a specific nightly version

[nightkr]

Pinning sounds good to me. It's not like we'd need to bump this more often than we already do for rustc anyway.

[sbernauer]

We decided to go with this in a daily last week. If there are any problems we can always revert this change

[Techassi]

VS Code users can use the following setting to override the command run on "Format on save":

"rust-analyzer.rustfmt.overrideCommand": [
  "rustfmt",
  "+nightly-2025-01-15",
  "--edition",
  "2021",
  "--"
],

Sadly, setting extraArgs did not work:

"rust-analyzer.rustfmt.extraArgs": [
  "+nightly-2025-01-15",
  "--edition",
  "2021"
],

I assume, the configuration for other editors will be similar.

[Techassi]

I also found two potentially interesting options to enable (which shouldn't be too controversial):

• reorder_impl_items
• use_field_init_shorthand

It might be worth to add them in a separate PR.