Check uses of _nullFuture for zone safety, add tests

[rakudrama]

Check uses of _nullFuture to see if they preserve zones properly.

An optimization to use _Future._nullFuture had to be reverted (73f45d6)
Apparently starting an async function has to use a Future in the current zone, even though the called 'then' function is wrapped in the zone.
Trying to optimize this to _nullFuture (in the root zone) broke a customer tests.

@floitschG I don't really understand why this should matter, since _Future._thenNoZoneRegistration creates another _Future in the current zone.

[floitschG]

Internal test run showing the problem:
https://test.corp.google.com/ui#id=OCL:160135719:BASE:160135823:1498482338190:746720b

[lrhn]

The issue here is that the when completing a future, it might schedule the calling of callbacks in the zone where the future was itself created. It won't always do that - if the future completer queue is already running, it will just be added to that. If the future is already completed when a listener is added, it will schedule that callback in the listener's zone.
It's basically a big mess, and some fragile code depends on the exact current behavior. Replacing a future with another future with the same value, but created in a different zone, may cause a scheduleMicrotask to happen in a different zone and throw off code which tries to "empty the microtask queue" (fragile behavior).

I hope to eventually remove the Zone from being a property of the future, and use the most relevant of:

• the zone where the future is completed, for the initial asynchronous completion.
• the zone of the listener, for later added listeners.

I also want to remove the concept of error zones, but until that, futures completed with an error should remember the zone where they were completed with that error, but that is only necessary for errors.