Add unstable .editorconfig support

[kleinesfilmroellchen]

• I did not use an LLM to create a change in this PR.¹
• I used an LLM to create a change in this PR, and I have explained below how it was used.

This PR adds unstable support for configuring rustfmt via .editorconfig.

Background and context

• #t-rustfmt > Technical reasons for not supporting .editorconfig
• Prior request: Editorconfig support #2999
• Prior art: Add support for generating .editorconfig from rustfmt configs #2999 #6701 and cargo-efmt

Detailed design and featureset

See also the zulip thread above, which gives a more detailed rationale as to why which option is supported in what way.

See the commit descriptions for implementation notes.

The following is copied from CHANGELOG.md:

rustfmt now has unstable support for .editorconfig, enabled with --unstable-features --use-editorconfig.
The following .editorconfig options are respected when applied to Rust source files:

[*.rs]
# These three options cannot be modified, as they do not have corresponding rustfmt options.
# If they are present at all, they are required to take on certain values:
# Required to be utf-8 or utf-8-bom.
charset = utf-8
# Required to be true.
trim_trailing_whitespace = true
# Required to be true.
insert_final_newline = true

# These options correspond to existing stable rustfmt options.
# Corresponds to hard_tabs (spaces => false, tabs => true).
indent_style = spaces
# Corresponds to tab_spaces.
indent_size = 3
# Alternatively, this combination sets tab_spaces via tab_width:
indent_size = tab
tab_width = 3
# Corresponds to newline_style (lf => "unix", crlf => "windows", cr is unsupported).
newline_style = lf
# Corresponds to max_width.
max_line_len = 100

Note that only the configuration for the entry point (e.g. main.rs, lib.rs, or integration tests) is respected, but not for child modules.
Use a [*.rs] section in your .editorconfig to avoid surprises.
There is no dedicated support in cargo-fmt; use cargo fmt -- --unstable-features --use-editorconfig to pass the option through to rustfmt.

Open questions

Since this is my first r-l and rustfmt contribution (but by far not my first time writing Rust code), I’m not confident about the following points:

• Should cargo-fmt have dedicated support for this feature? I deemed this unnecessary.
• Is there a better place to put documentation? I found that Configuration.md is the only proper documentation that rustfmt has, and it only documents options, not even the CLI or any detailed user-facing behavior. I put the documentation in the changelog for now.
• This PR adds a single new external dependency on a crates.io crate. Are there any special rules for this? Is it necessary (and possible) to exclude this dependency from the stable build for now?
• Are the tests OK to add in this form? It was the easiest for me (I largely copied cargo-efmt’s tests, which have 100% coverage on the code there), but it does add another integration test binary.
• I had to modify some parts of the public-facing rustfmt APIs, is there any special procedure/stability guarantee for that?

Misc

The test cases in this PR cover about 95% of the functionality introduced, according to llvm-cov (which is a better ratio than the rest of rustfmt :3), including every error case I could spot. Let me know if I missed anything.

This PR is not intended for squash-merging, and will be rebased/amended to address code review.

Footnotes

1. No slopmachine output has ever, or will ever, be used by me to author any software, including any communication on this PR. 100% cat-made software, meow >.< :3 ↩