implement trampolines for flatmap, map, filter, merge.

[myuwono]

in this PR

• implement trampolines for flatmap, map, filter, merge.
• Remove suspension point allocation in single shot builder.

fixes #2896

Context:

Arb.flatMap, Arb.map, Arb.filter and Arb.merge was previously implemented using callbacks, where it creates a new arb which .edgecase and .sample function directly calls the receiver arb's function. While this works for shallow nestings, on bigger nestings and more complex structures this approach can easily exhaust the call stack.

In this PR i implemented a simple trampoline to transform the receiver Arb<A> to TrampolineArb<A>. TrampolineArb<A> stores the initial arb and all subsequent operation chains inside a list, which will be executed in order of application. This allows us to compose a longer chain of flatMaps without blowing up the stack. Visually it looks like this:

receiverArb
  .flatMap { value -> fn1(value) } 
  .flatMap { value -> fn2(value) } 
  ...
  .flatMap { value -> fnN(value) } 

// translated to
`TrampolineArb(receiverArb)`
[
  () -> Arb0
  (sampleOrEdgecase) -> Arb1,
  (sampleOrEdgecase) -> Arb2,
  ...
  (sampleOrEdgecase) -> ArbN
]

That function will then be computed by collapsing the function list from left to right and applying the random source from the context of .sample(rs) or .edgecase(rs). If one is familiar with the trampoline implementation of Free Monad, this more or less the same mechanism implemented without tail recursion and trampoline data type.

Similarly within arbitrary { } builder, it appears that suspensions also has a limit on the number of suspension points that can be stored. Since Continuations are single-shot anyway, we can instead pass in the type of action that the call site needs, e.g. whether it is an edgecase generation or sample generation. This way we can get rid of the .resume() call within the .bind() in favour of just a simple return.