Replace pin-project with pin-project-lite

[ghost]

NOTE(taiki-e): It's recommended to see #2170 (comment), if you are considering to do the same as this.

Almost any program doing async I/O uses futures-utils, which pulls in syn and quote dependencies, causing compilation times to be much higher than is needed.

We should consider replacing pin-project with pin-project-line, which is not using proc macros.

cc @taiki-e

[taiki-e]

1. The first step is to merge Remove uses of pin_project::project attribute #2176. (done)
   Remove uses of pin_project::project attribute #2176 removes some uses of features that pin-project-lite doesn't support and switches the code to a style compatible with pin-project-lite.

2. After the Remove uses of pin_project::project attribute #2176 is merged, look at the code passing any argument to #[pin_project]. These features are not supported in pin-project-lite, so consider whether we can add it to pin-project-lite or write equivalent code without that feature and unsafe.

[ghost]

Looks like the first step is done :)

[taiki-e]

Yeah. Also, I filed taiki-e/pin-project-lite#25 to start evaluating the second step.

[taiki-e]

taiki-e/pin-project-lite#28 adds enum support to pin-project-lite. I'm wondering what syntax is preferable, so I would appreciate any feedback.

[taiki-e]

I've released pin-project-lite 0.2 with support for enum. We can probably start this partially.

[taiki-e]

This issue seems mentioned in some projects, which already depend on proc-macros.
For your reference, I'll leave a note:

• My recommendation as an author of both crates is to use pin-project whenever possible.
  I think pin-project-lite is a reasonable option only if reducing compile time is really important, and pin-project is the only proc-macro-related dependency.

• As mentioned in pin-project-lite's readme, if you already have proc-macro-related dependencies in your crate's dependency graph, adding pin-project to a dependency has little impact on compile time.
  I have previously investigated how little the effect is actually. See io: remove unsafe pin-projections and remove manual Unpin implementations tokio-rs/tokio#1588 (comment) for that.

• pin-project-lite is very lightweight, and compile-time does not change whether both pin-project and pin-project-lite are included in the dependency or only pin-project is included in the dependency.

• The error messages emitted by the current pin-project-lite are very poor and may require some knowledge of macro or pin API to determine if it is a macro limitation or a legitimate error.
  In fact, tokio and async-std had unsoundness that seemed to be due to a misunderstanding of this: io: fix unsound pin projection in read_buf and write_buf tokio-rs/tokio#2612, Fix double drop in StreamExt::cycle async-rs/async-std#903
  (They did unsafe pin-projections for something that the pin-project-lite didn't seem support, but the error is correct and manual pin-projections were unsound)
  pin-project has no limitation like pin-project-lite and can emit decent errors in most cases.