Version: Latest everything

This issue is related to #5687

When setting a value in an enumerable (array) within the debug windows, the debugger may not modify the underlying value depending on the implementation of the specific type. This is apparent with spans when you try to modify a value at an index in the debugger through the span. The value does not actually get updated on the source array.

As a result of the debugger not modifying the underlying value of the enumerable, the debugger seemingly throws away the new value and then just tries to recreate the enumerable copy for display within the debug windows.

We should have a way to modify the underlying enumerable variable values in the debug windows instead of trying to operate on read only copies that are created by the debugger when it displays in the windows... especially when the debugger shows the value modified when it is not.

Proposal:
The debugger can call the set indexer on the array type when the user modifies the value at an index in an enumerable.

Example:

1. I have a custom Span like type or other type that operates directly on pointers in the implementation. I want to show all the elements in the instance within the debugger.
2. I can implement a custom debug collection type that gets instantiated by the debugger during display. The type has an array set indexer.
3. The collection type is declared as a property in the type created in (1).
4. When the user modifies an element at an index through the debug windows, the set indexer is called with the newly created element. This gives enough information to modify the underlying pointers of the type in (1) directly as we have access to not only the index of the element but the new value of the element. The collection type in (2) would hold the base pointer value to the beginning of the block.

Remarks:
This issue could apply to visual studio as well, because it implements the same behavior.

After Debug.WriteLine investigation, it seems that the VSCode and VS debuggers do instantiate new copies of the arrays for the debug views quite often depending on if the user has expanded the collection or tried to modify a value within. As long as the set indexer in the proposal gets called before the recreation happens on each element modify, the proposal should work fine no matter how many times the debuggers recaches.