remove near-fmt dep from near-vm-runner

[Ekleog-NEAR]

Part of #8197

This changes the behavior, in ways that hopefully would not be problematic.

@jakmeier AFAICT you’re one of the last ones to have touched io traces, WDYT about this change?

[jakmeier]

Oh btw, I just realized that near-fmt is already published to crates.io, just like near-o11y.
I guess it's still good to remove the dependency but I'm not sure why this was strictly necessary.

[Ekleog-NEAR]

Oh btw, I just realized that near-fmt is already published to crates.io, just like near-o11y.
I guess it's still good to remove the dependency but I'm not sure why this was strictly necessary.

So technically, as near-fmt and near-o11y do not appear in the API of contract runtime (except for the format of log messages, which is actually the reason for this review, so… ^^’), it would have been possible to keep the dependency there.

However, both of them are currently published only as an internal detail because we need to publish near-vm-runner for sandbox and similar out-of-nearcore usage. So we often bump the major version, and it’d be iffy to try to sync that up with a separately-published version of contract runtime that’d have its own semver guarantees.

TLDR: we could have lived with the deps and make things somehow work in this specific case (because they don’t appear in the API of contract runtime), but it’d mean iffy handling of version upgrades if we didn’t decide to actually stabilize near-fmt into a proper crate in some way or form, similarly to what we did with finite-wasm.