Change implementation by trap bytecode methods with patched literals

[guillep]

run:with:in: is terribly slow.

Instead, use normal methods and literal patching.
This plays much better with the JIT and inline caches.

The general strategy is the following.

The original method is installed in the method dictionary with another selector (an object).
A trap method accepting the same number of arguments than the original method is copied, then it is patched so it forwards the message to the previously crafted selector.

Moreover, trap methods have been optimized to avoid allocating ensure blocks, stack reifications and other subtleties required for stack unwind (correct management of exceptions and non-local returns) which makes it very slow.
To fix this, this PR requires a change in how Pharo manages exceptions. See for example the code of ensure:

ensure: aBlock
	| complete returnValue |
	<primitive: 198>
	returnValue := self valueNoContextSwitch.
	complete ifNil:[
		complete := true.
		aBlock value.
	].
	^ returnValue

The key of the previous method is that when unwind is done, the methods with the marker 198 are found in the stack and then:

• if the antepenultimate temp (complete) is not nil
  • the first argument is taken (the handler block) and executed via the value message
  • and the antepenultimate temp (complete) is set to true

I improved Pharo so that the handler block is instead put in the first temp, allowing the method to have as many parameters as possible.

ensure: aBlock
	| handler complete returnValue |
	<primitive: 198>
        >> handler := aBlock. <<
	returnValue := self valueNoContextSwitch.
	complete ifNil:[
		complete := true.
		aBlock value.
	].
	^ returnValue

This way, trap methods can be written as:

trapWith: arg1 with: arg2
  | handler |
  handler := "some object that understands value".
  ...

This allows

• unwind without extra blocks and less contexts
• having a very fast execution path without unwind in the middle.

On top of this, the handler of traps is set as a literal that is patched.
That literal is a normal object (ProxyInstrumentationDeactivator) that on value inspects the stack (we are in the slow case anyways, who cares! :D) and performs what is required to do.

This PR requires the previously explained changes into Pharo, in pharo-project/pharo#14610

[guillep]

Waiting for the integration of pharo-project/pharo#14613

[jordanmontt]

The code is good and the PRs from the Pharo side are already accepted! So, for me, it's ok to merge. But, maybe before merging, we should have a release of the current commit for Pharo 11. Because when we will merge this PR MethodProxies will not work on Pharo < 12