m: Remove unnecessary dependencies from event-listener-strategy

[notgull]

• We never actually end up using pin_utils, it was a mistake to leave that in.
• We can get around pin_project_lite by implementing manual pin projection.

[fogti]

what does m: stand for?

[fogti]

it seems that this breaks MSRV but idk why...

[notgull]

what does m: stand for?

m stands for "maintenance". I use it for PRs with no public changes.

[fogti]

it would be nice to compare this side-by-side with the expanded version using pin-project-lite, to see how they get around the MSRV thingie...

[notgull]

It look like pin_project_lite just calls Pin::new_unchecked on the result of Pin::get_unchecked_mut. I adjusted this PR to use that strategy instead.

[taiki-e]

pin_project_lite just calls Pin::new_unchecked on the result of Pin::get_unchecked_mut

pin-project{,-lite} does not just call those unsafe functions. In this PR's macro, implementing Unpin or Drop on the generated structure or adding the #[repr(packed)] attribute to the input struct can cause unsoundness.

(Even though it may seem simple at first glance, using the unsafe parts of the Pin API correctly is not always easy. e.g., rust-lang/futures-rs#2649, tokio-rs/tokio#2612, etc.)

[notgull]

pin-project{,-lite} does not just call those unsafe functions. In this PR's macro, implementing Unpin or Drop on the generated structure or adding the #[repr(packed)] attribute to the input struct can cause unsoundness.

(Even though it may seem simple at first glance, using the unsafe parts of the Pin API correctly is not always easy. e.g., rust-lang/futures-rs#2649, tokio-rs/tokio#2612, etc.)

Hmm, this is a good point. Maybe we shouldn't remove pin-project-lite, just so that we can piggyback off of that package's guarantees.

[notgull]

Closed in favor of #56