This fixes the issue mentioned in this PR comment.

Bug & Steps To Reproduce

In essence, sometimes* the children of a property in the Properties panel are duplicated. Often, this happens for a brief moment, making the issue a bit hard to catch and diagnose. Here are some steps to reproduce (one example) in the demo app without having to modify the existing code:

1. Open the demo app.
2. Quickly select app-sample-properties.
3. Quickly expand the first prop – computedObject – in the Properties panel. This should happen before app-heavy is loaded.
4. Until app-heavy is loaded, the nested properties will be duplicated.

Obviously, there are minimal reproducible examples, but they require significant modifications to the app.

Culprit

After an extensive investigation, it appears that the culprit is the diff function which is in charge of finding the difference between and modifying the existing FlatNode tree by a provided new one in the property data source. Here is the exact mechanism of the bug:

1. The top-level properties of a specific component are loaded.
2. A consecutive automatic call is loading the first level of nested properties.
3. Respectively, the new FlatNode tree is fed to the diff function along with the existing tree without nested props.
4. Since the tree is represented as an array in the data source, for example:

{
  x: {
    x1: {
      x2: ...
    }
  },
  y: { y1 }
}

is [x, x1, x2, y, y2] where each property contains the level of nesting, all nodes except the first one are affected by the update (e.g. new nodes and moved nodes), meaning that in the given example only x remains unchanged.
5. However, x technically keeps (should keep) a reference to its children that is used to determine whether its children are loaded.
6. If the user expands x, the program determines that x doesn't have its nested properties loaded based on the reference.
7. This results in another nested props request that technically leads to the duplication of these props.

Fix

diff now performs an additional identity check and updates the items that haven't been moved or changed in any other way but their reference (respectively, internals).

Also, there are some unit tests to cover for the core diff operations.

@AleksanderBodurri, I think it's best that you review the PR since the code probably dates back to the very first versions of the DevTools. It seems that the bug is quite old.

* While the culprit of the bug was found and it's evident that the affected nodes are the ones which internals were changed but retained their position in the array (usually, first nodes in the array), I haven't delved into why the properties resolve or stabilize by themselves, so to speak. I assume it has to do with component tree updates triggering some sort of a refresh.