[Inference] request() returns a request context to avoid redundant makeRequestOptions calls

[hanouticelina]

Related to @SBrandeis's comment here #1292 (comment). This PR addresses the original concern about redundant makeRequestOptions calls introduced in #1292.The solution implemented here updates the request function to return both the response and a request context when needed, allowing provider-specific polling code to reuse this context without redundant calls to makeRequestOptions.

This differs from the initial suggestion in the comment as each provider implements polling differently with different parameters / response formats. Making a generic .poll property would require mixing provider-specific logic into the core request function (we don't want that, right? 😄 ).
In the end, we want to keep provider-specific logic isolated in their respective provider files (PR coming today to push that further!).

[coyotte508]

This PR adds different return types, not sure the complication is worth it (unless it saves network calls)

[Wauplin]

FWIW in the Python client we've deprecated the "custom requests" method to make it internal-only and gain some flexibility -which would prove useful here-.

[SBrandeis]

Nice!
I would be in favor of removing the request method from the public API as suggested by @Wauplin
Or at least, don't make the return type conditioned by a parameter (always return ResponseWrapper<T>)

[coyotte508]

just to reiterate a bit, it's totally fine to call a "light" sync function twice to simplify things

[hanouticelina]

I added a deprecation for custom requests through request and streamingRequest to be removed from the public API (I was not sure if I can just remove them directly or go through a deprecation cycle). I also made the inner request method to always return ResponseWrapper<T>.
Let's wait for @SBrandeis final review to see if it's still worth merging this PR or just keep the two call to makeRequestOptions as suggested by @coyotte508 (I'm okay with both solutions).

[Wauplin]

just to reiterate a bit, it's totally fine to call a "light" sync function twice to simplify things

AFAIU in this case makeRequestOptions is not a light function as it requires to fetch the provider model id from an HTTP call

[HuggingFaceDocBuilderDev]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[hanouticelina]

AFAIU in this case makeRequestOptions is not a light function as it requires to fetch the provider model id from an HTTP call

ah yes, forgot that we call api/models/{model_id}?expand[]=inferenceProviderMapping in makeRequestOptions, thanks!

[SBrandeis]

Super nice - thanks for keeping the diff very low !!

I have some suggestion regarding syntax / code style, otherwise LGTM

[SBrandeis]

let's goooo