feat(d1): add IntoFuture and #[must_use] to D1PreparedStatement

[eyupcanakman]

D1PreparedStatement holds a query that has not run yet. With no terminal call it compiles fine and does nothing, e.g. query!(&db, "DELETE FROM users WHERE id = ?", id)?;. Adding #[must_use] to the type makes that a compile warning, matching the KV builders (GetOptionsBuilder, PutOptionsBuilder).

#774 also asks for impl IntoFuture so a statement runs when you .await it. That would be the first IntoFuture in the crate, and await stmt has to pick one terminal method. I can follow up with one delegating to run() to match the JS stmt.run(), or all() if you'd prefer.

Part of #774.

[guybedford]

For the must_use I'm open to either way on this one. Formally it's not a correctness issue if it isn't used though.

For the IntoFuture on the query itself that would be great though definitely.

[eyupcanakman]

Added the IntoFuture impl so awaiting a statement runs it through run(). Kept the must_use alongside it, but can drop it if you'd rather this PR stay scoped to just IntoFuture.

[codspeed-hq]

Merging this PR will not alter performance

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

✅ 2 untouched benchmarks

---

_{Comparing eyupcanakman:feat/d1-prepared-statement-must-use (c3ec02f) with main (cc174db)}

[ajharhussain250-jpg]

Hi i am a workr and i hop you cansider me on x twitter. best wishise for you. your freind Azher Hussain Khuwaja.