[Bug] Possible race condition while using CommandLine

### [REQUIRED] Please fill in the following fields:

* Unity editor version: 2020.3.41f1
* External Dependency Manager version: 1.2.175
* Source you installed EDM4U: .unitypackage
* Features in External Dependency Manager in use: CommandLine
* Plugins SDK in use: Firebase
* Platform you are using the Unity editor on: Linux

### [REQUIRED] Please describe the issue here:
While using Unity editor in batch mode on Linux we can meet the race condition inside CommanLine class, especially in AsyncStreamReader.
Steps to reproduce:
* Install **python3** to your OS
* Clone a repo with a minimal reproducable Unity project: https://github.com/CheeryLee/EDM4U_TestLinuxFirebase
* Run `cd /path/to/unpacked/project`
* Make sure there are no _Library_ and _Temp_ folders. It's important to reimport the project from a clean state before every start otherwise Firebase's AssetPostprocessor won't work.
* Launch Unity with such arguments: `/Unity/Hub/Editor/2020.3.41f1/Editor/Unity -projectPath ./ -batchmode -quit -logFile /dev/stdout`. **Be careful:** you must use batch mode, not GUI.

#### Please answer the following, if applicable:
**What's the issue repro rate?**
Pretty often (I would to say more than often), but not 100% - can't find a strict dependency. But I can say the following things:

1. removing **Firebase.Editor.dll** solves the problem. Repro: 0;
2. removing shaders from project solvers the problem too. Repro: 0;
3. using them together causes troubles.

**What happened? How can we make the problem occur?**
The problem appears when Unity executes Firebase's realization of AssetPostprocessor class. There is a sequental execution of Python scripts inside it. On the first step the script tries to determine installed version of Python via runing `python --version` by `CommandLine`:
https://github.com/firebase/firebase-unity-sdk/blob/main/editor/app/src/PythonExecutor.cs#L129

You are lucky to find the issue at first try if you see these log entries:


If nothing happens after 10 seconds, connect a debugger and pause the program to see what's going on. I use Rider, so the screenshots will be from there. These are the points in different threads where resolver execution suspends:

1. `CommandLine.AsyncStreamReaderMultiplexer` waits for queued item to be ready to read:


2. `CommanLine.AsyncStreamReader` hasn't got a signal to free read event and thus hasn't fired `DataReceived` callback with completion argument:


3. Following the facts above we can't go on without `complete` event inside `RunViaShell` being set:


In all cases, where the problem appears, `DataReceived` callback in `CommanLine.AsyncStreamReader` would never be fired with `complete == true`.
It occurs immediately after the start of shader compilation, that's why I provide a bunch of the shaders along with project. Can't be sure either it's a race condition between different parts of engine or maybe a deadlock inside resolver.
The only one way to skip the waiting is to kill Unity process and run it again. But it's a completely not a solution for CI/CD environment. 😿