Redesign Web IDE state management of files and file changes

Description

Currently in the Web IDE, there's some tight coupling, duplication of state, sharing of objects between the various file collections in the Web IDE store.

• state.entries
• state.tree
• state.changedFiles
• state.stagedFiles

This hurts our maintainability, but also creates some hard to catch regressions and hacks when resolving file changes (because things are imperatively added/removed to the staged or changed bucket as opposed to reactively revaluated based on some virtual HEAD).

Proposal

Let's redesign how our Web IDE state tree for files and file changes... This will probably also solve &2433 (closed)

This issue should result in:

• An end-goal for how state should be organized and managed.
  • What does the ideal state tree look like?
  • After decoupling, are there any other modules/components this introduces?
  • What modules/components will be no longer relevant?
• An iteration plan for how to migrate the current codebase
• A rough POC
• A review from other FE maintainers/contributiors.

Objectives

• Reduce duplication of file object across state. The trees, entries, stagedFiles, openFiles, etc., all share references to the same file objects. This creates some tight coupling situations (i.e. I can read from the property changed but I'm not allowed to change it, only X_MUTATION can change it).
• Implement staged / changed as a result of watching file changes (like how Git works), instead of having each file change know how to update the staged / changed files.
• Reduce number of props saved for each file object.