Data Picker: be able to replace children elements in an expression, be able to get the runtime value of an element that is not a prop

[balazsbajorics]

The data picker's API evolved very organically, starting from only being able to pick data for a specific property of a selected element. This meant that the data picker relies on some assumptions that are no longer true:

1. the "current value" is no longer guranteed to be found in allElementProps
2. the target is no longer guaranteed to have a valid usePropertyControlDescriptions which we can use to get at the shape of the data, because propertyControls only describe props.
3. When replacing the current data with the new data, it's either a setProp_UNSAFE for an ElementPropertyPath, or a updateMapExpression (which changes the valueToMap field) – but setProp_UNSAFE doesn't work correctly for replacing a single child in an array of children.

The DataPickerPopupProps already introduced the concept of the DataPickerType that can be DataPickerForAProperty or DataPickerForAMapExpressionValue. But then the internal code doesn't carry this information forward, instead just uses null for the PropertyPath wherever it would be applicable.

Instead of the nullable propertyPath passed into usePropertyControlDescriptions and usePropertyValue, we should refactor the internal code too so there's a clear separation of concerns: the -actual- data picker logic needs:

1. a currently spied value, if exists
2. the shape of the object we are looking for, if exists.

For the case of DataPickerForAProperty, the old code should be used.
For DataPickerForAMapExpressionValue, we have two options: we can keep it map.valueToMap specific, or we can do a similar refactor to the one in DataReferenceCartoucheControl, which uses childOrAttribute: JSXElementChild; surroundingScope: ElementPath as the input.
I'd personally advocate for taking and exploring this latter route:

1. based on { childOrAttribute: JSXElementChild; surroundingScope: ElementPath } we can get a runtime value using the fresher variablesInScope system
2. Instead of a map-specific updateMapExpression action, we could have a generic REPLACE_ELEMENT_IN_SCOPE action which uses { childOrAttribute: JSXElementChild; surroundingScope: ElementPath } to be able to hunt down the exact JSXElementChild inside the relevant ParseSuccess. this could fix the bug of not being able to replace a specific child in an array of children nodes, but also work for map.valueToMap.
3. The generalized code could be applicable everywhere we want to show cartouches, because in every place it is correct to talk about a childOrAttribute: JSXElementChild as the replacement target.

Downsides to consider:

1. using only { childOrAttribute: JSXElementChild; surroundingScope: ElementPath } as the information means we need a new set of helper functions which are capable of replacing a JSXElementChild in a ParseSuccess with another JSXElementChild.
2. for insertion use cases we still need the old ElementPropertyPath to work because there is no childOrAttribute to replace.

[bkrmendy]

#5690 addresses the problem of replacing a single child in an array of children

[balazsbajorics]

@bkrmendy can you write down what are the remaining tasks here?

[bkrmendy]

#5755 added a new data picker, and #5780 removes the one that "inspired" this issue, so I'm closing the issue and file the problems with the new data picker as separate issues