Rename poll_oneoff to poll_list, add poll_one

[sunfishcode]

The name "oneoff" was never very evocative, so I propose we rename it to poll_list because it polls a list of pollables.

Also, for convenience because it's a common case when writing simple examples and when compiling blocking code, I propose we add a poll_one function that just takes one pollable.

I'd ideally like to make these changes at the same time as converting to resources, to minimize churn in downstream users.

[lukewagner]

On the topic of changing these APIs: in addition to renaming, I'd suggest returning a list-of-ready-indices (instead of a list-of-bools) and/or having a poll that takes a list and returns a single pollable index (avoiding list allocation in the common single-ready case).

[cpetig]

Wearing my functional safety hat I want to avoid all allocations at runtime, because they easily introduce unpredictable delays into the system (unless you replace the allocator with a more complex bounded time implementation).

So I wish there were also a non-allocating variant of this call, my proposal would be to add a non-allocating variant for the common up-to-64-pollables case:

poll_up_to64: func (in: list<pollable>) -> bitflags64

Of course this involves adding a way to express constant size list as bitflags.

(I am mostly concerned about the main loop of a service implementation where this function constantly polls which input stream to process next and might often return without a wait)

Update: Removed the borrow from the signature as it is default for imported functions.

[sunfishcode]

In WebAssembly/wasi-io#46 I'm proposing to do the rename of poll-oneoff to poll-list and make it return a list of indices, and add poll-one.

I have not yet proposed any changes for the single-ready case. In any approach where we return fewer events than have actually occurred, an implementation would need to associate a buffer of pending events for each pollable, which would add some complexity, so I've chosen to defer that for now.

I also have not yet proposed any changes for poll-up-to64. My assumption is that with some work in the bindings, we can avoid actually performing a dynamic allocation, perhaps by maintaining a static buffer to be reused for poll calls. But if I'm wrong, it'd likely be easy to add this.

[sunfishcode]

WebAssembly/wasi-io#46 has renamed poll_oneoff to poll_list, and added a poll_one. I didn't yet add a poll_up_to64; feel free to file an issue in the wasi-io issue tracker to discuss this.