Since {CancelAndWait} blocks on the tasks that are still present in the internal
hashmap, we are not allowed to remove the task upon trying to cancel it using
{TryAbort}.

The previous implementation suffered from a bug where:
1) The task was created and handed over to the platform.
2) The task was started by the platform, setting it to running state.
3) We called {TryAbort}, effectively removing it from the manager, but failing
   to cancel (as it was already running)
4) All tasks finished running, indicating this with their own semaphore.
5) The platform was stuck (scheduling) before destroying the task.
6) Main thread finished its work, waiting for all the necessary tasks, and the
   isolate terminated.
7) The platform destroyed the task, calling the destructor, calling into an
   already freed isolate.

BUG=chromium:524425
LOG=N

Review URL: https://codereview.chromium.org/1460763004

Cr-Commit-Position: refs/heads/master@{#32118}