API change: replace loop and forObject callbacks with cfRoot/cfBlock

[alexjordan]

This proposed change avoids trying to map the underlying to instrumentation signals into higher-level constructs.

It addresses the following issues with the previous API in #48:

• Duplicate callbacks issued to loop and forObject API
• Lack of filtering of conditional events in loop callback
• cfBlockEnter/Exit are now anchored to their parent root via parentIID

[Haiyang-Sun]

@alexjordan So here the test code reveals that when there is a customized iterator defined, the last expression might not be the target object for the for in/of event (but the last expression executed in the iterator function).

How about we track the last expression value executed at each stack frame? In this case, we should still be able to know the object being iterated without complex logic checks?

[alexjordan]

@Haiyang-Sun in general it would be nice to have an easy way (ideally directly exposed by Graal.js instrumentation) to communicate which object is being iterated over. But in the end it depends on the analysis. When an object has a custom iterator and an analysis is interested in data flow, the object is not enough, the analysis has to analyze the iterator code as well.

[Haiyang-Sun]

@alexjordan I agree. I like the example analysis here to illustrate how it can be used for such a complex use case. I just propose to add a simple and easy-to-understand analysis example to show the for in/of event with the object. I will add a PR later to this branch.