Allow selecting a backend per client

[cavivie]

Nyquest currently relies on one process-global backend. That works well for the preset path, but makes it difficult for an application to use different native transports or for a library or test to inject a backend without changing global state.

This adds custom_backend to ClientBuilder. A builder uses the registered global backend by default, while callers can explicitly provide a backend for an individual client. The resulting client remains type-erased, so the backend type does not propagate through application APIs.

The existing global registration and missing-backend panic behavior remain unchanged.

This implements the custom backend per client part of #1. It is also useful groundwork for per-client Android backend selection discussed in #52, but does not add a Cronet backend itself.

Tested with:

• async-only and blocking-only client backend tests
• cargo test -p nyquest --all-features
• cargo clippy -p nyquest --all-targets --all-features -- -D warnings

[bdbai]

Regarding custom backends this is what I have in mind: db820ca. wdyt?

The panic with no global backend configured is meant to highlight the incomplete setup to the end user as early as possible. I still suggest keeping it as is.

[cavivie]

Thanks, this approach works for our use case. I've updated the PR to use the generic builder state and custom_backend(&backend), while keeping the existing global registration and missing-backend panic behavior unchanged. The tests still cover multiple clients using different backends without global registration.

[bdbai]

thanks!