Update fuzzing loop and fix optimization mode

[anishnaik]

Closes #498

The primary purpose for this PR is to be able to solve the problem disclosed in #498 which highlights that shrinking in optimization mode is insanely inefficient. The way the current fuzzing loop is structured, each time a new maximum value was identified, the optimization testing provider was forced to request a shrink request. There was no way for the provider to request a "one-shot" shrink request at the end of the campaign.

Thus, we had to make a few core changes. First, we needed to capture when the fuzzing campaign is about to end but there is at least still one fuzzer worker alive that can handle the final shrink requests from the optimization provider. So, we introduced a new fuzzer worker event that the optimization provider subscribes to which allows the provider to request shrink requests right before the fuzzer is torn down.

The problem with the new solution is that we still need to allow the user to ctrl+c if they don't want the shrinking to complete. So, we had to create two fuzzer contexts: the main context and the emergency context. The main context is cancelled when a timeout is hit or when the test limit is hit. The emergency one is triggered by a SIGINT/SIGKILL or if an error occurs in the core fuzzing loop.

To support all of this we had to update the core fuzzing loop as well to handle the two different contexts and the ability to handle shrink requests before shutting down.