Add async-std support

[TheButlah]

Review #109 first - this is based on that.

To avoid contributing to the fragmentation of the async ecosystem, I think its really important to support both tokio and async-std. Additionally, async-std is the only runtime that has wasm support currently, and it is a personal goal of mine to get this project capable of running in the browser and communicating over web sockets (see #64).

You can control which version via feature flags, as this seemed to be the canonical approach in other projects that can use either runtime (like async-tungstenite) for example. I've left the default runtime to be tokio, as it seems to be the more popular and fully featured option.

In terms of the complexity of maintaining two versions, the two libraries present an extremely similar api. In most places, the wrappers I wrote are a drop in replacement for whatever we were using before, and you can see that with just wrappers for spawning tasks. everything else is just in how transports are implemented, and even there the code doesn't diverge much. I had to add some beginner-unfriendly cfg statements in the example code, but that is a small price to pay for being able to build all tests and examples in either version, rather than just the source code. Also, both tokio and async-std are 1.0 now, so we shouldn't need to worry to much about changing APIs.

I also now test both tokio and async std in the CI. This should ensure that our code operates on both versions.

[Alexei-Kornienko]

Mostly LGTM. Could you please add some description in README explaining how to properly build/run examples with different runtimes? IMHO examples become a little bit more complicated cause now they support both runtimes.

[TheButlah]

@Alexei-Kornienko OK, I've updated the readmes. Hows that?

[Alexei-Kornienko]

@TheButlah looks great. Thanks for working on this.