Better align shutdown semantics of testing event loops

[simonjbeaumont]

Motivation:

The two testing event loops—EmbeddedEventLoop and NIOAsyncTestingEventLoop—have different semantics for outstanding work during shutdown, which are both different from the production SelectableEventLoop, specifically with newly scheduled tasks that result from running existing scheduled work at the time of shutdown.

There are three axes to consider:

1. Scheduled tasks that are at or past their deadline.
2. Scheduled tasks with a deadline in the future.
3. Newly scheduled work that result from either running or cancelling (1) and (2).

	(1)	(2)	(3)
SelectableEventLoop	Run	Cancel	Quiesce over 1000 ticks, repeatedly run resulting (1) and cancel resulting (2)
EmbeddedEventLoop	Run	Cancel	Cancel resulting (1) and resulting (2)
NIOAsyncTestingEventLoop	Run	Run	Run resulting (1) and resulting (2)

Note that NIOAsyncTestingEventLoop may never terminate because of this.

Modifications:

This PR aligns EmbeddedEventLoop and NIOTestingEventLoop and makes them more similar to SelectableEventLoop and less surprising semantics.

Result:

	(1)	(2)	(3)
SelectableEventLoop	Run	Cancel	Quiesce over 1000 ticks, repeatedly run resulting (1) and cancel resulting (2)
EmbeddedEventLoop	Run	Cancel	Cancel resulting (1) and resulting (2)
NIOAsyncTestingEventLoop	Run	Cancel	Cancel resulting (1) and resulting (2)

Future work:

Given both the EmbeddedEventLoop and NIOAsyncTestingEventLoop are used in tests of NIO applications that run with SelectableEventLoop in production, it might be worth extending both to also support quiescing to give a more representative shutdown behaviour in tests.

[simonjbeaumont]

@FranzBusch I just disabled automerge on this one because I wanted you to +1 the updates to the threshold JSON. I'll have another PR with update to the dev script for making this easier.