fun: switch to async IO

[bcoe]

c8 already requires a bleeding edge v8 engine, we should switch to async/await rather than using any synchronous IO.

see @TimothyGu's comments in #8.

[Bnaya]

@bcoe what do you think about typescript? :)
I would love to help refactor the codebase to typescript + utilising async functions

[bcoe]

@Bnaya 👋I'm not a huge advocate of Typescript; part of why I'm excited about native coverage support in v8 is that it can eliminate some of the transpilation that is currently being performed by Istanbul.

But! I would love your help on c8; if you'd like to contribute, strike up a conversation with me in this Slack:

http://devtoolscommunity.herokuapp.com/

[profnandaa]

@bcoe - would like to take up this one (for fun :)). I can't seem to get the code that is being referred here:

see @TimothyGu's comments in #8.

in bin/c8.js, do we rewrite rimraf (has Async API) and mkdirp (no async, so means rewriting with fs.mkdir going for the new fs.mkdir)?

Do we also change the fs.*Sync's in /lib/parse-args.js and /lib/report.js too?

[bcoe]

@profnandaa I'd have a preference with just using the new fs.mkdir, but this is something we could patch in Node.js itself; just switch the command used in Node's coverage to set recursive true.

I think we could switch everything that's blocking to async/await, with some fiddling with flow control -- the main advantage I see to doing this is that Mozilla's source-map library is async now:

https://github.com/mozilla/source-map

[profnandaa]

@bcoe -- I'll be on it, hopefully should raise the PR tomorrow (going to bed now).

Thanks for the heads-up about the Mozilla project, checking it out 👍

[bcoe]

@profnandaa thank you for this contribution.