WIP chore(log): migrate std/log to use the Web Streams API

[syhol]

Tackling this issue: #3907

Whats left to do in this PR:

• Tests need updating
• Race conditions need handling and testing
• Figure out how destroy is handled by callers now that its async
• Understand how to "unload" works with promises and if we need to do something about the destroy handler
  • It does not wait for promises to resolve, this is potentially a big problem as this means we will always lose the last write when the flush is async.
• Should new properties use protected or #hashName
• Delete PR specific comments
• Understand why double dispatch exists on the "Window unload flushes buffer" test
• Support multiple calls to destroy.
• Remove delay(1) from "Window unload flushes buffer", detect when unload handler is finished
• Remove delay(1) from "FileHandler: Critical logs trigger immediate flush", detect when unload handler is finished
• Either un-export LogQueue or move it to std/async/???.ts
• Write more tests

Initial Idea:

• Replacing BufWriterSync with Buffer from std/streams/buffer.ts
• Using the magic line this._buf.readable.pipeTo(this._file.writable); to pipe the buffer to the file once full.
• Change as little as possible

I'm not sure how much time I can dedicate to this over the next few weeks so if anyone wants to pick this up, you are welcome to.

[syhol]

Test are now passing.

Big changes since the last review are:

• The log string is now encoded into a Uint8Array much earlier in the process, this means we only need to do it once rather than 2 or 3 times.
• LogQueue is a new class which essentially converts synchronous calls to .enqueue into an AsyncIterable. We use this to make sure:
  1. All logs have been written when calling flush
  2. We only process one log line at a time making sure we avoid race conditions with either flushToBuffer or rotateLogFiles. I'm not 100% sure there would be race conditions now, but it could be easy to introduce in the future.
  3. See here for further justification
• Flush is now async, that means destroy is now async, this has a knock-on effect on a few things, especially tests.
• We now re-create the Buffer (not the ArrayBuffer just the wrapper) each time we flush to file. I'm not sure if it's intended behaviour but if we don't recreate the Buffer it fails to write any data after the first flush.

@iuioiua would you mind taking a look at the changes? I've added some questions and TODOs in comments in the code.

I know LogQueue might seem a tad over-engineered, but it feels like a really nice abstraction and could be used for other things (see the comment about moving it). If the logic was implemented inline in the FileHandler class it would just add complexity to an already complex class.

I'm open to critical feedback, and looking forward to progressing this PR. I'll try to spend a few more hours on it over the holidays.

[syhol]

Due to the fact that the unload lifecycle event handler does not await promises, using the async streams API is very risky as the last flush on unload would not complete.

As an alternative I've created this new PR #4021 that keeps to synchronous functions. It removes all std/io and Deno.Writer references and uses a plain ArrayBuffer and Uint8Array to buffer logs. Also it's a very small diff compared to this PR, only +22 −13.

[iuioiua]

Closing in favour of #4021.