feat: Add .editorconfig for consistent formatting

[rabestro]

Hi team,

This pull request introduces a .editorconfig file to the root of our repository.

Motivation

I'm proposing this change to address a common source of friction I've experienced, where commits fail in CI simply due to a missing final newline in a file. By defining a core set of formatting rules that are automatically applied by most code editors, we can eliminate this entire class of errors and make the contribution process smoother for everyone.

As I wrote about recently on my blog, this single file can help unify formatting across our team's diverse development environments.

Benefits of .editorconfig

• Automated Consistency: Automatically enforces basic rules like line endings, character sets, and the presence of a final newline.

• Reduced CI Noise: Prevents trivial CI failures, allowing us to focus on the substance of our changes.

• Editor Agnostic: It's a single, standard configuration file supported by a vast range of editors and IDEs (including JetBrains IDEs, VS Code with a popular extension, Vim, Emacs, and more). This avoids the need for editor-specific settings files.

• Opt-in Enhancement: For contributors whose editors support it, the experience is improved. For those who don't, nothing is enforced, and our existing CI linters will still act as the final backstop. It's a helpful enhancement, not a strict requirement.

About This Configuration

I've created this configuration file based on a detailed analysis of our repository's structure. Key decisions include:

• Universal Standards: Enforces UTF-8, LF line endings, and the crucial insert_final_newline.

• Language-Specific Indentation: Sets appropriate indentation for .awk, .bats, .json, and .yml files.

• Flexible Line Length: max_line_length is intentionally unset for .awk and .bats files, as our analysis showed that many example and test files contain long lines with embedded data that shouldn't be wrapped.

• Respect for Generated Files: Rules are explicitly unset for files we don't edit, like LICENSE and fetch-configlet, to prevent unintended changes.

I'm very open to discussion on this file. Please feel free to review, comment, and suggest any changes. Let's make this configuration work perfectly for our track!

Looking forward to your feedback.

[IsaacG]

Looks good to me but I'm curious what Glenn has to say.

[glennj]

I'd never heard about it before this. I'm OK with adding it.

[ErikSchierboom]

It's fairly common in the C# world AFAICT