refactor: add concurrent promise pooling for render task

[zhangyx1998]

fixes #3362

This PR provides a more efficient approach of limiting the concurrent promise memory usage by introducing a "Pool" model. Other than using "batches" of tasks (as implemented in #3285) which waits for all tasks to finish before dispatching next batch, this approach dispatches a new task upon the conclusion of any currently running task.

Currently the thread count is hard-coded as 64. I plan to make it available for user configuration later.

Changes Made

• Added an utility (pool.ts) to "src/node/utils/":

  This utility provides a easy-to-use API of controlling the amount of microtasks dispatched to the JavaScript event loop.

  In addition to its basic use case when you need multi-process pooling (like Python's multiprocessing.Pool), it can also optimize memory utilization by limiting the amount of local enclosures and garbage-collecting them as soon as possible.

• Refactored "src/node/build/build.ts":

  Instead of using Promise.all from either the original code or Improved Build Efficiency for Large Blog with Batch Processing: Prevent Javascript heap out of memory #3285, I introduced the pooling mechanism enabled by the above mentioned utility.

Future Improvements

• Provide user configuration for max_threads.

Additional Comments

This is the first PR I've ever created. I would appreciate any comments on errors or mistakes I made in this PR.

[brc-dd]

I've changed the implementation to directly use p-map instead of maintaining a pool implementation here. I've tested it locally both your Pool and pMap give similar performance (109s build time / 2.73GB peak memory usage).

[sr2ds]

great job @zhangyx1998 , congrats!

[zhangyx1998]

great job @zhangyx1998 , congrats!

Thanks!