Update .editorconfig fix accessibility issues

[ttytm]

This PR makes some minor fixes as the current setting unfortunately creates some confusion in the editor.

It wants to:

• Fix shifting tab widths and misalignments when e.g., switching splits in VSCode or entering buffers in nvim. It also should fix not respecting a users tab width setting.
  

  This issue is due to specifying indent_size as an anti-setting for tabs.
  Unlike with spaces, specifying a width is not needed; one tab is always one indentation. Without it we'll get the benefit of increased accessibility and more developer friendliness, so any preferred indent width can be used or dynamically adapted to a given situation. If you check https://editorconfig.org/, you will also see # Tab indentation (no size specified).

  I would further suggest to move towards a more modern setting for indentation for odinfmt that takes either an int or "tab" as value indendation=int|"tab". Like e.g. stylelint does https://stylelint.io/user-guide/rules/indentation#options

• Extend file support. Yaml unfortunately requires spaces, as my editor didn't behave properly when working on Renovate and extend CI workflow #264, so .editorconfig was extended to cover yaml files.

[DanielGavin]

The reason tabs_width exists is not for tabs itself, but when you are breaking lines when they exceed line width. If there is no tab_width it could get quite wonky when someone makes a billion scopes, but we act like the tab is just one space, but on the editor it is 4-8 spaces.

It's one of shortcomings of tabs, formatter is operating in an uncertain environment.

I still prefer having a config to get a compromise between pretending tabs is one space.

Would to hear your opinion on how to manage line breaking when odinfmt uses tabs.

Example:

func :: proc() {

    {
        {
             {
                 {
                     a := 2 //this would in spaces be 28, but 12 with tabs pretending the symbol is one space
                 }

             }
        }

    }

}

[ttytm]

Hey @DanielGavin,

Please excuse the long response time.

Solid point regarding the number of characters used per indentation level when calculating the line length or breakpoint!

Common approaches to solving this are either hardcoding the width per tab indentation level to something like 4 (resulting in actual code line length + indentation_level * 4), or making it configurable via a dedicated setting, as is currently done with the tab_width value.

To proceed from here, and since the tab_width key serves a purpose in odinfmt.json, one suggestion would be to downsize the changes and just update the .editorconfig to follow the convention of not specifying an indent_size when tabs are used. This would suffice to resolve the shifted indent lines issue mentioned in the PR.

Let me know what you think and if there is a preferred way to proceed. I will do my best to be quicker with follow-up responses. Thanks for keeping up the work!