[P12][P13] Fixing bug that raised NodeNotFound when an object-centric permalink was installed on a slot defined by a superclass of the object class

[adri09070]

Fixes #16548

When installing an object-centric permalink on a variable slot, the method registerAndInstallPermaLink:forTarget: takes all nodes that access this slot and it installs the metalink on the equivalent nodes in the anonymous subclass of the object:

registerAndInstallPermaLink: aPermaLink forTarget: aSlotOrVar
	| nodes |
	(linksRegistry canReinstallPermaLink: aPermaLink)
		ifFalse: [ ^ self ].

	linksRegistry registerPermaLink: aPermaLink.

	nodes := (aSlotOrVar accessingNodesFor: aPermaLink persistenceType) asIdentitySet.
	aPermaLink targetObjectOrClass link: aPermaLink link toNodes: nodes

However, if the target variable slot has been defined by one of the superclasses of the object, it does not exclude the accessing nodes that are not in the object's class hierarchy (so: the nodes from methods that are in brother/cousin classes). As a result, it will try to find equivalent nodes in the anonymous subclass but these nodes do not exist so an exception NodeNotFound is raised.

This breaks object-centric debug points, for example

I fixed that method to only keep the accessing nodes that are in the class hierarchy of the target object.

[adri09070]

Some VariableBreakpoint tests fail because the fix break the semantics of non-object-centric variable breakpoints:

My fix is necessary if the permalink target is an objec, however the same method is called to install non-object-centric permalinks.
However, when we set a non-oc variable breakpoint on a variable in a class, it considers that the breakpoint should hit if an access is performed in any of the subclasses of the class that defined the target slot.

While the fix, as it is shared with oc variable breakpoints, considers that the variable breakpoint should hit only if the access is in the class hierarchy of the target class (i.e: the class of the object) (which is to me not a bad semantics, else why let the developer choose a target class? Moreover, my semantics allows to have better control on when the breakpoint should hit)

This should be discussed. Does the semantics need to be changed? Should I change the fix to stick to the old semantics for non-object-centric variable breakpoints? Anyway, variable breakpoints should be completely replaced by variable debug points .

 @StevenCostiou