Fix copy on write behaviour in QuiescingHelper

[cameron-robey]

Fix a copy on write issue in QuiescingHelper that led to significant performance problems when the number of channels became large, or connection churn.

Motivation:

When using QuiescingHelper, every channel holds onto a reference to ChannelCollector, which leads to copy on write behaviour for openChannels[]. This has performance issues when a large number of channels are open (e.g. 25k channels can be hundreds of KB), and every time a channel is opened, or closed this is copied. As accepting channels happens on a single NIO thread, this work is all done on that thread, and can lead to saturation, and no more channels being accepted.

Modifications:

Move the state into a non copyable LifecycleStateMachine, to avoid the copies.

Result:

Overhead from ChannelCollector disappears (as seen in traces from http://github.com/apple/swift-profile-recorder).

[weissi]

CC @glbrntt / @adam-fowler / @0xTim / @Joannis This should give gRPC, Vapor and Hummingbird a speed boost when accepting and holding lots of connections. Currently, accepting connections can cause CoWs on a dictionary holding all active connections. So this can be pretty bad!

Fantastic work @cameron-robey finding and fixing this!!

[Lukasa]

@cameron-robey Looks like there's a consuming annotation that we threw in for minor refcounting benefits that the older compilers are struggling with. I recommend throwing that away for now, should fix up the builds.

[Lukasa]

Very nice, thanks @cameron-robey!