[ios][android] support return value for native module APIs someway

[Jinjiang]

For example getItem(key) in storage module. It's more simple and familiar with web developers.
Of course from the perf aspect, this kind of API is suitable for non-frequent calls only.

[sospartan]

It's a very very bad idea:
0. Break 'js-native' bridge.
0. Performance issue.
0. Nobody will like do IO operation in sync way.

[littleseven]

Maybe we can refer to the design of JSON-RPC.
1)Notification. (no return)
2)Request and Response.

[MrRaindrop]

If this issue is solved, then the timer api module will be valid to use again.

var timer = require('@weex-module/timer')
var id = timer.setTimeout(function() { /*none*/ }, 1000)
timer.clearTimeout(id)

even though the timer can be set and clear by calling setTimeout/clearTimeout directly, still we like the require way because the consistency of using 'require' to require a API module.

And maybe there occurs another using case in another day. I think the ability should be prepared to solve such problems.

[Jinjiang]

The more valuable thing of this is we provide module developers the ability of both mechanism for sync & async pattern. Neither keep all module APIs async nor switch all module APIs into sync mode. The module developers could make the choice on their own.

Take storage module for example, this is a very simple k-v pairs data storage, not necessary to implemented by a SQLite database and async/callback APIs. This could be more easily to implement and use.

Thanks.

[Jinjiang]

This discussion is moved to #1677
Thanks.