EPIC: Componentization of PyFluent

## Theme IV — Componentization of PyFluent

This issue addresses a long-standing idea: to **componentize** PyFluent so that its core layers are modular and interchangeable.

### Motivation
Currently, PyFluent’s client layer uses Fluent’s gRPC interface. We would like to introduce more flexibility here:

- **Swap communication backends** — for example, replacing the gRPC client layer with a REST client layer, without affecting higher-level PyFluent modules.
- **Use PyFluent as a lightweight process controller** — e.g., exposing only APIs for launching, monitoring, and terminating solver processes.
- **Enable cross-product reuse** — allowing other solvers or products to integrate into a common Python platform using PyFluent’s architecture as a foundation.

### Architectural Implications
To achieve this, we’ll need to:
- **Decouple PyFluent from `flobject`**, the current Python base class underpinning Fluent’s Settings API object types.
- `flobject` is too Fluent-specific to serve as a general base.
- At the `.proto` level, however, the Settings API is **generic and reusable**, which is encouraging.
- **Adopt or develop a more generic framework** to replace `flobject`, ideally one that:
- supports **static attribute encapsulation** (avoiding redundant API calls),
- and can serve as a **common base** for other solvers and service layers.

### Goals
- Define a **component boundary** for PyFluent’s transport/client layer.
- Demonstrate that PyFluent can run transparently over REST or gRPC.
- Prepare the framework for **multi-solver integration** within a shared Python ecosystem.

No files or tests are identified. Start by mapping the current flobject relationship and the generic Settings API at the .proto level, then define the transport/client boundary and how REST or gRPC can be used without changing higher-level modules; done means these componentization goals are demonstrated and the framework supports multi-solver reuse.

Written by the indexing model from the issue text.