make Greenwood CLI and plugins async through and through

[thescientist13]

Type of Change

• New Feature Request
• Documentation / Website
• Improvement / Suggestion
• Bug
• Other (please clarify below)

Summary

Coming out of #532 , where I had tried to do some async operations in the provider of a plugin, that it dawned on me that should we really be better committed to, and consistently, implementing async in Greenwood.

Details

The main issue is that to do something like this, everything has to become async, which is fine, but we just have to design around it so that we can support async and non-async functions alike, with one API. This is because await will automatically wrap return values in Promise, so in that way async is backwards compatible, unlike a sync version

This would also be a good time to fix "faux" async where we use it inside for forEach and reduce functions, which when actually forced into an async context, fall apart, since those Array methods are sync. We should probably use more for ... in.

Bonus, the async variants of fs methods can take an instance of URL natively, so we wouldn't have to use pathToFileURL in those situation. - I think this is now handled as part of #948

---

Notes

• Should consider this along with Standardize on Web APIs (Request / Response / URL / etc) #948
• As per the above, not all things can be done async, like middlewares for the server or bundling, since order matters. But anywhere else where we can parallelize, we should.
• async provider plugins

OR

Should use sync more, in sync cases like within a map or filter.