.editorconfig

phases: add an internal phases

The phase is meant to be used for internal commit that are a byproduct of
command operation (eg:shelve).

This changeset focus on getting the most important feature in, more advanced
API is to be introduced in later changesets.

The phase approach to handle internal has multiple advantages:
* simple to implement, reuse optimized code,
* fits well with existing phases. We don't want internal changeset to be
  exchanged or served.
* easy to extend to for lifecycle handling.

More thinking about internal changeset at https://www.mercurial-scm.org/wiki/InternalsPlan

We add this new phases with a high number to leave some room to possible other
phases. We also try out playing with the idea of "flag" for phases, each flag
would convey a distinct meaning. We can drop the flag idea in the future
(keeping the existing numbers). The flag property should still move in a
monotonic direction (enabled -> disabled) or be immutable like the "internal"
flag.

To simplify the addition of this new phase, we introduce many placeholder
phases. They are not meant to be used for now. Keeping `allphases` as a list
ensure existing algorithm works fine.

The full performance impact of adding that many hollow phases is unclear so
far. The impact on phase computation is visible but not worrisome.

Runnin `hg perfphase` in my mercurial development repository.
Before: ! wall 0.001807 comb 0.000000 user 0.000000 sys 0.000000 (median of 1597)
after:  ! wall 0.001906 comb 0.000000 user 0.000000 sys 0.000000 (median of 1521)

# See http://EditorConfig.org for the specification

root = true

[*.py]
indent_size = 4
indent_style = space
trim_trailing_whitespace = true

[*.{c,h}]
indent_size = 8
indent_style = tab
trim_trailing_whitespace = true

[*.t]
indent_size = 2
indent_style = space
trim_trailing_whitespace = false