[WIP] Remove async send_signal method, defer to subclass

[kevin-bates]

After validating the downstream modules that can use async kernel
management (notebook and enterprise-gateway) it was found that
the async send_signal method was not warranted since it doesn't
return an awaitable and deferring to the subclass's sync version is fine.

I'm fairly certain this is the last of the "touch-ups" for the async kernel management changes. Thanks for your patience.

[davidbrochart]

No problem @kevin-bates, iterating is necessary.
However when I suggested to not implement signal_kernel as a coroutine, you said rightfully that other implementations (those managing remote kernels) could be async.
Note that even though signal_kernel doesn't await on anything in this implementation, it is still a valid coroutine and works as fine as making it a blocking function and not awaiting on it (I mean, it doesn't hurt to leave it async).

[kevin-bates]

Thanks for questioning this @davidbrochart. yes, I remember that comment and forgot to reference it in the PR description. Having this be async was causing failures in Enterprise Gateway leading to NoneType can't be used in 'await' expression. I'll keep looking and have moved this to WIP in the meantime.

[davidbrochart]

Then it probably means you have your own implementation of signal_kernel in Enterprise Gateway, which is not async.

[kevin-bates]

Damn, you're spot on - found that just prior to reading your response! I'll likely close this PR, but want to run more tests again.

[kevin-bates]

Thank you! That was indeed the issue. Closing now.