Add warning for experimental functionality

[stinodego]

With 1.0.0 around the corner, we want to more officially indicate experimental functionality. Right now, it's just a comment in the docstring. This is not sufficient.

Definition

If functionality is considered experimental, this means:

• It may not work exactly the way you would expect it to.
• The API or implementation may change without it being considered a breaking change.

Examples

• The Decimal data type works in some parts of our API, but it is largely unimplemented (e.g. arithmetic). It may be fine to use in specific contexts, but is not yet as reliable as other numeric types.
• The LazyFrame.collect(streaming=True) works and will produce correct results, but it may not fully operate in streaming fashion and consume more memory than expected.

The extent to which functionality is experimental will differ. We can elaborate in the docstring when warranted.

Proposal

• Users will get a PolarsExperimentalWarning when using experimental functionality.
• This warning can be turned off globally in the Polars config by setting Config.set_experimental_warning(False).
• Affected classes/functions/parameters get a warning admonition in the docstring.

Implementation

• We add a decorator on classes/functions that are considered experimental. This decorator automatically inserts the warning and dynamically updates the docstring.

Comments welcome - especially looking for better names for the Warning / Config setting.

[jmakov]

If streaming=True and streaming isn't supported, it would be great to get that info in the warning e.g.

• streaming not supported at all for the streaming source: PolarsExperimentalWarning("Streaming not yet supported for source 'scan_arrow_dataset'")
• query can be only partially streamed: PolarsExperimentalWarning("This query can be only partially streamed")
• no warning if the query can be fully streamed