Create Babysitter for Cached Compilation Worker for Compiling JS Libraries

Every engine maintains a separate worker for compiling the incoming JS library code. Due to multiple reasons, this worker can fail and become unresponsive. In such cases, it must be recreated.

To achieve this behaviour, we must implement a babysitter wrapper component to wrap the compilation worker.

The babysitter wrapper component should perform the following tasks:

1. Recreate the compilation worker and destroy the previous (failing) compilation worker.
2. Provide an abstraction to allow us to access the current healthy compilation worker for compiling the incoming JS library.

Addtionaly, setting a heap size limit of 1 GB for compilation for the entire process's lifetime may not be suitable as there may be scenarios/times where this heap size limit may be too much or too little depending on the load. There is scope to configure the heap size limit to achieve better memory efficiency.

For example:
In the steady state of the system, when no new apps are being loaded or no existing apps are being modified, this upper limit of 1GB of memory can be reduced for the compilation worker so that the GC can be requested to run and release unused memory, this would free up memory for other processes improving the memory efficiency.

The value of `compilationWorkerQuota` is just a guide for the GC thread on when to act and attempt to force GC. With 1 GB on the compilation thread, the GC thread will rarely interfere (i.e. only when the heap size comes close to 1 GB). All workers and V8 isolates are defined with a 1.4 GB limit by default before the near_heap_limit callback gets invoked. In a later patch when we will use the quota to set this 1.4 GB limit to a lower value and estimate old and young generation sizes, then `compilationWorkerQuota` would need to be updated.