This is an attempt to address issue #10339.
Background:
Currently, the `editor.tabSize` option does two things - it specifies the width of the tab character and it specifies how many columns to advance when the tab key is pressed. However, there is code in the wild that has a mix of spaces and tabs that expects these two values to be different.
These generally use and indent size of 2 or 4 and spaces are used for indentation until the indent becomes >= 8. The tab character size is excpected to be 8 and groups of 8 spaces are replaced with a tab character. Indent levels end up looking like 2 spaces, 4 spaces, 6 spaces, 1 tab, 1 tab + 2 spaces, and so on.
Implementation:
In the editor options, a new option, `editor.indentSize` is added. This, in conjunction with `editor.tabSize` has the same semantics as `indent_size` and `tab_width` in the well known [EditorConfig specification][1].
> indent_size: a whole number defining the number of columns used for each indentation level and the width of soft tabs (when supported). When set to "tab", the value of tab_width (if specified) will be used.
>
> tab_width: a whole number defining the number of columns used to represent a tab character. This defaults to the value of indent_size and doesn't usually need to be specified.
[1]: editorconfig.org
The new `indentSize` option takes a numeric value or "tab" just as EditorConfig's `indent_size`. The default value is set to "tab" so that current default behavior of VS Code does not change and existing user settings will not break.
When getting the new `indentSize` option programatically, it always returns a numeric value (just as `tabSize` does when set to the deprecated "auto" value).
In the text editor model, a new property is added for `indentSize`. Unlike the configuration options where the value of one property influences the other, In this code `tabSize` now should only mean "the width of the tab character" and `indentSize` should only mean "how may columns is one indent".
The cursor operations and shift command are updated to reflect these new semantics.
Part of #62110
Use the more generic name as suggested in https://github.com/Dart-Code/Dart-Code/issues/1393. This makes the intent of the field more clear and also allows us to extend the concept of preferred code actions to refactorings and other classes of code actions
Experimentally also allows a `preferred` value for `apply` when configuring code aciton keyboard shortcuts. This applies the preferred code action returned from the list of code actions returned
Part of #62110
- Adds a new field `canAutoApply` to code actions. This field indicates that a code action can be applied without additional user input. For quick fixes, this should be set if the fix properly addresses the error
- Enable auto fixes for TS spelling errors
- Added a `editor.action.autoFix` command to triggers auto fixes at the current cursor position
