Switch to using futures-micro for things it supports. Resolves #6, #7, #8

[jjl]

I ended up moving a few things from here into micro (which now has better docs!).

New features: or!, poll_state, zip!

Everything else is just not duplicating things micro now has and minor tidying.

[bugaevc]

• What's the point of having ready() if it does the same thing as async { }?
• What's the point of having poll_state() if a closure can store its own state?

[fogti]

@bugaevc I deprecated these functions (incl. pending(), which is also superfluous).

[taiki-e]

• This adds a dependency on a lot of unsafe code that doesn't seem to be documented at all.
• Since futures-micro's major version is less than 1, it is basically unacceptable to re-export their types directly. Please wrap them using the new-type pattern.
• This adds additional unneeded Unpin requirements to some types of Unpin implementations. (breaking changes)

Also, futures-micro's readme says something like this:

Yes, we could get rid of them with pin-project-lite, but it's just hiding the mess and then we couldn't claim zero dependencies.

"just hiding the mess" is not correct. pin-project/pin-project-lite guarantees the safety requirements required for pin-projection, at compile time. (See pin-project's docs for details)

I've seen a lot of unsound code in a project that made similar claims and using unsafe code before, and I'm worried that futures-micro will be in the same state in the future.

[jjl]

This PR is very old, I think probably the right answer is to close it at this point, but i could bring it up to date if you wanted. Notes:

* This adds a dependency on a lot of unsafe code that doesn't seem to be documented at all.

Yes, the code currently assumes the implementer knows what they're doing. Yes, that's suboptimal.

* Since futures-micro's major version is less than 1, it is basically unacceptable to re-export their types directly. Please wrap them using the new-type pattern.

This PR predates futures-lite 1.0. Though we will probably release futures-micro 1.0 soon.

* This adds additional unneeded `Unpin` requirements to some types of `Unpin` implementations. (breaking changes)

I'll add it to the list of things to look at when I get time.

Also, futures-micro's readme says something like this:

Yes, we could get rid of them with pin-project-lite, but it's just hiding the mess and then we couldn't claim zero dependencies.

"just hiding the mess" is not correct. pin-project/pin-project-lite guarantees the safety requirements required for pin-projection, at compile time. (See pin-project's docs for details)

I've seen a lot of unsound code in a project that made similar claims and using unsafe code before, and I'm worried that futures-micro will be in the same state in the future.

That's interesting to know. At some point I will make a move to pin-project-lite in light of this.

[fogti]

@jjl about the unpin stuff: I think pin-project-lite might have been able to detect the pinning guarantee violation which was present in the past in next_poll...

[jjl]

That's interesting to know. At some point I will make a move to pin-project-lite in light of this.

This one is now done in main. The rest require a little more thought.

[notgull]

I'm going to close this. futures-micro hasn't been updated in over a year, and at this point it mostly just re-implements code that's already in here.

Thanks anyways for the PR!