[FEA]: Configure rapidsmpf runtime through cudf-polars configuration system

[TomAugspurger]

Is your feature request related to a problem? Please describe.

#20161 is adding a rapidsmpf runtime for executing cudf-polars queries. A few spots there could use values from the cudf-polars configuration (existing or new). This will become especially important in a multi-GPU setting.

• rapidsmpf spilling threshold: https://github.com/rjzamora/cudf/blob/7aa7dc8a1244570fa622179f977b4c82d1b7504f/python/cudf_polars/cudf_polars/experimental/rapidsmpf/core.py#L97-L102
• RMM memory resource to use (Add MemoryResourceConfig to cudf-polars config #20042 is relevant here, since it allows for more customization of the RMM memory resource)

Describe the solution you'd like

Any rapidsmpf configuration values should be configurable through the cudf-polars configuratoin system.

Describe alternatives you've considered

The workarounds for now are to use the rapidsmpf options, set directly ahead of time, etc.

Additional context
Add any other context, code examples, or references to existing implementations about the feature request here.

[rjzamora]

+1 from me.

Most of the "complication" here comes from the fact that we currently use a different execution model for single- and multi-GPU execution:

• For single-GPU execution, we use the client process to generate the plan/task-graph and to execute it.
• For multi-GPU execution, we only use the client process to generate the plan/task-graph. We rely on a Dask cluster with distinct worker processes to actually execute the tasks.

This distinction means that some multi-GPU worker characteristics (e.g. memory-resource type and spilling threshold) is configured separately from cudf-polars. I'm a bit worried that this convention will be tricky to change.

Perhaps a reasonable short/medium-term solution is to introduce client-specific configuration options for the memory-resource type and spilling threshold?