Exceptions from fetch handlers should wait for output gate.

[kentonv]

Prior to this, if an application queued a storage write, then threw an exception, and the storage write failed later on, the exception might nevertheless be received by the caller. If, for some reason, an application were confirming writes by throwing exceptions, this could result in confirming a write that didn't actually make it to disk.

Of course, surely no app does that. The bigger problem is that this could screw with the durableObjectReset flag on exceptions thrown after storage breakages. Say a storage write fails, and we respond by simultaneously throwing an exception from the storage API to the application, as well as breaking the output gate with the same exception. The version of the exception thrown at the application could propagate out of the fetch handler before the output gate had a chance to propagate its version. However, the version that throws through the application would lose the broken. annotation, as this by design does not transit through application code. The version of the exception that broke the output gate keeps this annotation, so is a better one to throw to the client. By properly waiting for the output gate here, we can make sure the preferred exception is propagated.