Only process received messages after the discovered targets have been stored.

…sages unchanged.

This fixes some of the unit tests, which were failing due to changes in the order of execution of initialization messages.

…sing return when ignoring a target.

…_logger field is initialized.

* Fixed a deadlock that could happen if the connection is closed on the thread that is processing received messages. TaskQueue could not be disposed on the same thread that held the semaphore.
* Fixed a race condition if targets are created/changed concurrently before the TargetHandler is registered as an event handler.

… thread A could invoke `TaskQueue.Dispose()` and set `_isDisposed = 1`, which would then allow thread B to finish work setting `_held = false` but without releasing the semaphore, and then thread A would attempt `_semaphore.Wait()` entering a deadlock.

…t having discovered all targets.

This was causing unit tests such as PuppeteerConnectTests.ShouldSupportTargetFilter to fail because the test executed faster than the target discovery.

…hat new targets are added to `_attachedTargetsByTargetId` inside of the semaphore.

Also fixes `Page.CloseAsync()` which was returning before `Target.CloseTask` resolved. This affected BrowserContextTests.ShouldFireTargetEvents on which it was possible for the test to finish before the `TargetDestroy` event.

It was possible for the InitializeAsync to finish without all targets being initialized, and consequently the test would read an empty list of targets.

The _targetDiscoveryCompletionSource should be awaited before logic that depends on _targetsIdsForInit inside of message processing, to make sure this collection was already initialized during the browser launch.

…stingPage.

Disposing the `browser1` was closing the page, which then caused the `Page.CloseAsync()` in `PuppeteerPageBaseTest` to fail.

The test code now matches upstream puppeteer.

…nSource`, as a defensive measure against deadlocks.