Fix autocb for fat arrow functions.

[davidbau]

This fixes #148.

Previously, when generating fat arrow functions with (autocb) =>

The (function(_this) { return function(autocb) {..} })(this) would get transformed into the incorrect form: (function(_this) { autocb(function(autocb) {..}}))(this)

Now we put an explicit non-autocb-return into the fat arrow binding to avoid this problem. This change also adds a test for this case.

[davidbau]

I've modified this pull request. It turns out the actual underlying problem is that node.icedHasAutocbFlag is interpreted in two different ways for Code blocks.

• inside Code:compileNode and Code:icedPatchBody, it's used to tell if this function itself has an autocb parameter.
• inside Base:makeReturn, it's used to tell if the node is within an autocb function.

The problem is that a function with an autocb parameter can appear inside a function that does not have one, and the two senses of this flag need to be different. In the previous iced code, it is makeReturn that can be fooled.

Unfortunately, makeReturn isn't passed any argument revealing the parent node, so it depends on the walk to give it an accurate icedHasAutocbFlag value Therefore, I've fixed icedHasAutocbFlag to mean "I am inside a function with autocb", and NOT "I am a function with autocb."

I have added the Code-specific icedIsAutocbCode flag that means "I am a function with autocb."

There are two simple cases where this problem appears, and I have tests for both cases:

f = (autocb) => 0
await f defer x

m = (v) -> (autocb) -> v
g = m 1
await g defer y

[maxtaco]

Thanks for this fix! Merged and published to npm in v1.8.0-d.