feat(DAPP-7422): move from lazy promise to async result

[jeffrifwaldsmartcontract]

• Proposal for removing reliance on LazyPromise
• Separating the initial capability call and the result call defers the blocking call until the result function is called/awaited
• Follows common promise patterns and doesn't rely on user avoiding calling await or then
• Below are a few other possible comparisons

// A. This is what is proposed in this PR, a single await for the result
const p1 = basicAction.performAction(input1)
const p2 = basicAction.performAction(input2)

const r2 = await p2.result()
const r1 = await p1.result()

// Inline awaits is simple
const inline = await basicAction.performAction(input1).result();

// B. We could also only promise at the action level, which makes it obvious that the result call is synchronous/blocking
const p1 = await basicAction.performAction(input1)
const p2 = await basicAction.performAction(input2)

const r2 = p2.result()
const r1 = p1.result()

// Inline await is still simple
const inline = await basicAction.performAction(input1).result();

// C. We could potentially require awaiting at both levels, like in fetch
// This is arguably the most technically correct pattern, but it is annoying to work with inline/shorthand
const p1 = await basicAction.performAction(input1)
const p2 = await basicAction.performAction(input2)

const r2 = await p2.result()
const r1 = await p1.result()

// Inline awaits are more cumbersome, but this is also how fetch looks
const inline = await (await basicAction.performAction(input1)).result();

// D.  Lastly, we could not use promises at all since neither of these function calls actually benefit from promises
const p1 = basicAction.performAction(input1)
const p2 = basicAction.performAction(input2)

const r2 = p2.result()
const r1 = p1.result()

// Inline requires no await
const inline = basicAction.performAction(input1).result();

In each of the cases above, the code never blocks until calling .result() on an action. This makes it much more intuitive as to what is happening than the magic with a LazyPromise. In order I prefer A, D, C, B, but I'd like to see what @ernest-nowacki and @ryannelsonsmartcontract think about these proposed patterns.

[ernest-nowacki]

This is great!

First of all I never really liked the LazyPromise, just couldn't get out of the box to see how else to solve it. Awesome that you've figured this out!

As for the proposals I would say A or D lands closest with me. D because it feels very much like "it is what is is" - we don't introduce any async where the calls are not async. Kinda like node's api mkdirSync and similar. A because it does feel more intuitive that you would actually await stuff like fetch calls. It's also very familiar with how with native fetch you would call await result.json().

Finally my vote: A.

[jeffrifwaldsmartcontract]

A @ernest-nowacki Once #69 is merged I'll update this PR so you can avoid major merge conflict headaches.

[ernest-nowacki]

No worries, I will just merge it now actually as changes aren't so bad - I will merge the one from the generator and then rerun generate scripts 👌