Support core.async channel for a parallel fun-map

[robertluo]

The idea is to provide a ValueWrapper for ReadPort and a channel aware function wrapper.

The channel value wrapper should have a special return value (more general than a ReadPort), if direct unwrap (e.g. not invoking by a function wrapper), just <!!, when invoking by a function wrapper, it will extend to something like (go (<! this)), and cause the whole function wrapper to be surrounded with a big go macro.

[robertluo]

A channel with single value does not follow deref semantic, it turns a plain value into channel, therefore the caller (accessor) must also know the difference of a channel (or ReadPort) and a plain value.

One idea is to pass ValueWrappers' a special map which provides same way for accessing value and channel, then wrap all the function with a go macro.

[robertluo]

Three way co-operation:

1. ValueWrapper of a channel should return a function instead of a value.
2. When a wrapped entry detect a function unwrapped, it calls the function on the map itself.
3. The function wrapper should accept a channel instead of a map as it’s argument. If the argument is a channel, it should wrap all its body in a go macro.

[robertluo]

Upon more research, core.async's channel does not represent semantic of a value, but a queue. The manifold deferred, future are more suitable for this.