Improve Solver Settings Enum API: Discoverability, Typing, and Round-Trip Symmetry

## Motivation

PyFluent solver settings already expose enum-like values at runtime, for example:

```python
solver.settings.setup.models.viscous.model.DETACHED_EDDY_SIMULATION
```

These enum values are discoverable via tab completion and `dir()` in a live Fluent Python session, but they are **not surfaced in the generated API reference**, nor are they encouraged by the current string-centric `set_state()` / `get_state()` API.

As a result:

* Users primarily interact with solver settings as **raw strings**
* Enum usage is effectively hidden and weakly documented
* Round-trip usage (`set_state` → `get_state`) does not preserve enum types
* IDEs, static tooling, and documentation provide little guidance

This issue proposes evolving the Settings API toward a **modern, Pythonic, enum-first interface** that prioritizes discoverability, safety, and usability over strict backward compatibility with early alpha releases.

---

## Current Shortcomings

1. **Enums are undocumented**

* Enum values (e.g. `DETACHED_EDDY_SIMULATION`) do not appear in generated API docs under the relevant setting.
* Users reading documentation are unaware that enums exist.

2. **The primary API path is string-based**

* Users are guided toward:

```python
model.allowed_values()
model.set_state("k-omega")
```
* Enum usage is not obvious or encouraged.

3. **No round-trip enum support**

* `set_state(enum_value)` is possible
* `get_state()` always returns a string
* This discourages enum adoption and prevents symmetric APIs.

4. **Weak IDE and typing support**

* Enum values are dynamically generated and not statically visible.
* Static analysis, autocomplete, and type checking are limited.

---

## Proposed Direction

Introduce **first-class, documented enum types** for enum-valued solver settings, and evolve the PyFluent Settings API so that enums are the *recommended* interaction mode.

This proposal repositions strings as a legacy / low-level interface wherever enums are supported.

---

## Proposed API Shape (Illustrative)

```python
from ansys.fluent.core.solver.enums import ViscousModel

model = solver.settings.setup.models.viscous.model

# Preferred usage
model.set_state(ViscousModel.K_OMEGA) # K_OMEGA also availalble under model

# Backward-compatible usage
model.set_state("k-omega")

value = model.get_state()
assert value is ViscousModel.K_OMEGA
assert str(value) == "k-omega"
```

---

## Acceptance Criteria

### 1. First-class enum definitions

* Enum-valued settings expose a real `enum.Enum` (or equivalent) type.
* Enum types are statically defined and importable.
* Enum members are visible to IDEs and static analysis tools.

### 2. Documentation visibility

* Generated API reference documents:

* The enum type
* Its members
* Its relationship to the setting
* Enum usage examples appear in the official documentation.

### 3. Enum-friendly setter

* Settings accept enum values directly via the primary setter (e.g. `set_state()`).
* String values remain supported for backward compatibility.

### 4. Typed getter support

One of the following must be true:

* `get_state()` returns the enum type when an enum exists, **or**
* A clearly documented typed getter exists (e.g. `get_enum()`), **or**
* `get_state()` returns a value object that:

* Compares equal to both the enum and the string
* Is convertible to `str`
* Preserves enum identity where applicable

### 5. Backward compatibility

* Existing string-based code continues to function.
* No silent behavior changes that break common usage patterns.

### 6. Discoverability and ergonomics

* Enum usage is discoverable via:

* Documentation
* Autocomplete
* Examples
* Users are naturally guided toward enum usage without requiring special “enum mode” APIs.

---

## Non-Goals

* Removing string support entirely
* Perfect backward compatibility with undocumented alpha behavior
* Solving all dynamic-attribute documentation issues in one change

---

## Benefits

* Safer, more expressive APIs
* Better IDE and documentation support
* Improved user confidence and discoverability
* Clear migration path toward typed solver settings
* Alignment with modern Python API design principles