Issue: Improve Beta Feature Visibility Control in PyFluent

# 🗂️ Issue: Improve Beta Feature Visibility Control in PyFluent

## Current Status

PyFluent currently provides users with a **session-level method** (`enable_beta_features()`) to activate beta features. However:

- The **settings API** does not yet support the concept of hiding or exposing individual *beta-level* items based on this flag.
- As a result, even if the `enable_beta_features()` switch is used, there is **no mechanism** to dynamically hide or reveal beta settings objects or properties.
- There is also currently **no trustable mechanism** to ensure developers properly classify or gate such features.
- Example: `materials.database` remains visible in the API but is really just a thin, unstructured TUI wrapper — it arguably should not be exposed as part of a stable API surface.

## Problem

This means:
- Users may see **unfinished, low-quality, or redundant API items** that appear fully supported but are actually experimental.
- There is **no clear, consistent signal** to developers or downstream tools about which parts of the API are stable vs. beta.
- There is a **risk of accidental usage** of non-final parts of the API in production workflows.

## Proposal

To address this, consider:
- Introducing **explicit beta path tagging** for all settings API objects, parameters, and methods intended to be gated.
- Allowing PyFluent to maintain its **own internal list of beta paths**, decoupled from developers' manual filtering.
- Linking this list directly to the `enable_beta_features()` switch, so that non-beta users cannot access or see these paths.
- Providing clear warnings or structured metadata when beta items are exposed.

## Example Use Case

The current `materials.database` situation illustrates this gap:
- It is visible to users but behaves like an old-style TUI object.
- There is no practical reason for it to appear in the documented stable API surface at this stage.

## Benefits

- Clearer boundaries between stable and experimental capabilities.
- Reduced accidental reliance on unfinished or unreviewed features.
- Stronger alignment with the intended **quality promise** of the PyFluent API.
- Improved ability for LLMs, IDEs, and doc tools to respect feature maturity.

---

**Request:** Please share design ideas for how we could implement and maintain this more robust beta feature control.