Otherwise things behave badly if we want to do a WaitUntilConnected when the runnable is already queued up to the main thread message_loop.

The problem is as follows: When we are forced to wait synchronously for plugin initialization (for example a script is querying for a property), we might need to wait for the plugin container to launch. Normally the runnable would be enqueued to the main thread and would eventually execute. Unfortunately in this scenario. That won't work in this case because the main thread must block until the plugin has launched, so in this case we execute the runnable immediately. Without this patch, we could have a scenario where the process launch runnable would be enqueued to the main thread and PluginProcessParent::mLaunchCompleteRunnable is then set to nullptr. When the main thread tries to execute the runnable immediately, it sees a null runnable (which is incorrect), does not finish setting up the plugin process, and then tries to do stuff with the plugin. This fix ensures that the runnable pointer is non-null until it executes either immediately or from the main thread message loop.

(Ignore the "Unfortunately in this scenario.")