Fix clippy and compiler warnings across client and server crates

[merkle-maren]

Warnings surfaced while working on #1628. Merging these separately - they're independent from that work and trivial to review on their own.

Changes

• Removed unused lifetime parameter 'a from process_connection in the server crate.
• Fixed mismatched_lifetime_syntaxes warnings in http-client and ws-client test helpers by using explicit 'static lifetimes consistently.
• Suppressed dead code warnings in core::client for types only used when async-client or async-wasm-client features are enabled (FrontToBack, BatchMessage, SubscriptionSender, etc.).

Motivation

cargo clippy and cargo test -p jsonrpsee-http-client produced ~14 compiler warnings. Mix of an unused lifetime, inconsistent lifetime syntax, and dead code from types gated behind feature flags not active in all compilation contexts.

Clean builds should be clean. Warnings that linger get ignored, and ignored warnings hide real problems.

Test plan

• cargo clippy --all-targets --all-features — zero warnings.
• cargo test --features tls — zero warnings.

[jsdw]

All of these #[allow(dead_code)]s I would guess (without checking myself) are feature flag related, and the relevant things should be hidden when the feature(s) they are used for aren't enabled, rather then ignored via dead_code (which might legitimately mean they aren't needed anywhere)

[jsdw]

I would have thought that adding '_ fo the BatchResponse type would also work here, but the proper equivalent would be adding a 'a lifetime in the generic params and using that. Elided / unnamed lifetimes aren't the same as static lifetimes.

[jsdw]

As above

[merkle-maren]

Removed all #[allow(dead_code)].

These trigger warnings on cargo test -p jsonrpsee-http-client but not on cargo test. I couldn't find a feature flag or conditional compilation path that accounts for the difference. Rather than suppress warnings we don't fully understand, I've dropped the annotations and fixed the lifetime warnings directly.

Open to a better approach if you know the exact cfg gate here.