style: cargo fmt --all across the workspace

[virtualritz]

Mechanical, whitespace-only cargo fmt --all to satisfy the repo's own rustfmt.toml. The tree was previously not fmt-clean (the config enables options the code was never formatted against), so cargo fmt --all -- --check failed repo-wide. After this, it exits 0.

• No semantic changes -- pure formatting (~124 files, per rustfmt.toml).
• Unblocks a hard CI gate: once merged, the advisory fmt --check step (added in Fix reachable-panic unwraps (non-breaking) + add justfile/CI gates #114) can be flipped to enforcing.

Merge order

Because this touches ~124 files it will conflict with every other open PR. Merge this last, then a fresh cargo fmt --all regenerates it in seconds if needed -- do not hand-resolve conflicts. Refs the blueprint vet.

[AdrianEddy]

Please don't... The automatic formatter is terribly ugly for this kind of crate

[virtualritz]

@AdrianEddy could you a tad more be specific?

clippy and rustfmt are PR/CI gates for most crates I have contributed to since years. And one of the great benefits of Rust is that there is an official way to format code: rustfmt with default settings.

It means I that wenn I look at Rust code from other people how they format is never an obstacle in reading the code. It was many times in the 25 years I had to look at other people's C/C++ code so I'm rather grateful for this.

If you don't like any of the additional choices in rustfmt.toml I'm very happy to change these or add some that you think will benefit this crate. Just open a PR.

But this PR will be merged one way or another, sooner or later for the reason given above.

[AdrianEddy]

I have nothing against rustfmt in regular rust crates, but this is a macro-heavy code on top of the Adobe API from the 80's.
Almost every change in this PR is for the worse in my opinion:

• The suite modules became 5x longer with a spaghetti stream of vertical code, with functions indistinguishable from each other
• It's harder to spot mistakes in blocks where we have to repeat functions for every data type
• Usage of the iteration suites is terrible, where closure parameters blend in with the iterate_with arguments and it's not clear where the actual user closure starts
• Parameter setup in examples looks worse, again too many vertical lines without a clear separation
• In places where you need to handle calls to different functions because of data type or bit-depth and where every parameter is the same otherwise, now you have to manually reason about every parameter to see if it's the same, because each one is on different line. Before you'd immediately see if they are correct because they were directly under each other

This is not something rustfmt.toml can fix, and adding #[rustfmt::skip] to every function is not reasonable.

I simply don't see any advantage of running rustfmt on this crate. To me it's a change to the worse for no benefit whatsoever.

But I guess now that AI is maintaining all the code anyway it doesn't matter and I can't stop you anyway.

Concrete examples: