Adding possibility to add bindings in debugger context interaction model

[adri09070]

This is experimental code that will be used to add bindings in the debugger code presenters. This could be used to instrument code by manipulating objects from anywhere in Pharo, in order to debug something. I think this is quite in adequation with the "playground programming style" that Pharo has.

Notably, I would need this for Chest, which is a debugger extension that allows to store objects from anywhere in Pharo and to load them into any playground (or debugger if this PR is accepted): https://github.com/adri09070/Chest
In the end, we will try with @StevenCostiou to load any object from Chest in any method by annotating its AST

[MarcusDenker]

Very interesting! We already had requests for that (for the inspector pane especially).

One thing we need to check if reading bindings from the workspace still works in the debugger:

• open a playground
• define a binding there "hello := 1"
• open a debugger with "hello halt"
• can we read the 'halt' variable still when we are in the debugger?

I should make an image with this...

[adri09070]

I tried on my Chest image and, yes it works. In the code, I prioritize context variables over presenter variables.

A problem I've just discovered, though, is that you can't execute code in the debugger, except manually. Because, to do that, the method needs to be saved and asks to declare variables as temporary or instance variables, which is not what we want. And cancelling doesn't save the method, of course. Anyway, the goal is not to save the code as the added variables couldn't be accessed outside the debugger they were added in.

It's more complicated than I thought and maybe it's not worth devoting time to this until we have a version of that with metalinks to allow to add variables to the method AST instead of the presenter?

[StevenCostiou]

Could this be simplified by something like

self bindings associationAt: aString ifAbsent:[nil]

?

[adri09070]

Yes, you're right.

We can replace

(self hasBindingInInteractionModelOf: aString)
 				  ifTrue: [ self bindings associationAt: aString ]
 				  ifFalse: [ nil ]

by

self bindings associationAt: aString ifAbsent:[nil]

[adri09070]

done

[MarcusDenker]

I think this is good to add as, if the additionals bindings are not set, it should have no impact at all.

This is a good step, we already had a request for allowing workspace style bindings in the inspector evaluation pane, for example. And this would be a step to experiment with these things.