Ship a 1.0 release

[thejpster]

Part of https://github.com/rust-embedded/wg/issues/383

Add blocking issues here:

• [x] can run cargo test neither on stable nor on unstable - #24
• [x] Review against https://rust-lang.github.io/api-guidelines/ - #31
• [x] Document MSRV - #30
• [x] Remove unstable feature - #32
• [x] CI on GHA + bors - #23 #24
• [x] Only include await! in Rust nightly via build.rs? - #28
• [x] Bump version in cargo.toml - #33
• [x] Add version section in changelog - #33
• [x] Release 0.1.3 semver-trick version - #34
• [x] :tada:

[hannobraun]

I guess the main blocking issue would be, whether this crate offers the right approach at all, and whether/how it needs to change (or be discarded completely) in the face of the async stuff that already landed in Rust, and is yet to come. See https://github.com/japaric/nb/issues/14, https://github.com/rust-embedded/embedded-hal/issues/149, and https://github.com/rust-embedded/embedded-hal/issues/172.

[eldruin]

I would nominate #22 for this.

[eldruin]

Further TODOs:

• [x] Review against https://rust-lang.github.io/api-guidelines/
• [x] Remove unstable feature
• [x] CI on GHA + bors - #23 #24
• [x] Only include await! in Rust nightly via build.rs?

[jonas-schievink]

• [ ] Remove unstable feature
• [ ] Only include await! in Rust nightly via build.rs?

I prefer the current approach of having to opt into unstable features. It mirrors how unstable features in Rust work, and if we automatically enable unstable feature for nightly Rust versions people could accidentally start using an unstable feature in this library just because their installation happens to default to the nightly Rust channel (which is a reasonable thing to do in order to use unstable compiler flags and benefit from recent performance improvements, etc.).