feat: support emitting event generator thunks

[neilcampbell]

Interested in your thoughts on this one.

I noticed that the algod.status endpoint was always called twice when waiting for the block at the tip, which felt slightly wasteful. It is called to retrieve the last round, which is used for emitting the before:poll event and used inside getSubscribedTransactions.

Two ways I thought about solving this:

1. Get the current round once and pass the value when creating the before:poll event and pass as a parameter to getSubscribedTransactions via TransactionSubscriptionParams.

   Pros:

   • Conceptually simpler
     • Ensures current round value is consistent across a single poll

   Cons:

   • It's a breaking behaviour change to getSubscribedTransactions, if someone is using it directly.
   • Requires fetching the current round prior to calling getSubscribedTransactions

2. Support event generator thunks inside eventEmitter.emitAsync (this PR).

   Pros:

   • We have a pattern to defer logic to only run when a subscription exists.

   • No breaking changes.

     Cons:

   • If you subscribe to before:poll, multiple status calls will be made.
   • It's possible to get different current round values for a single poll (current logic in main has this behaviour as well)

What option do you prefer?

[robdmoore]

As discussed let's implement this instead as syncTo?: number in getSubscribedTransactions and if it's undefined then it should do teh current behaviour.