Proposal: Use OpenAPI-generated client as foundation for fossology-python

First of all, I would like to thank all contributors who have worked on **fossology-python**. The project provides a very useful and practical way to interact with the FOSSology REST API. It adds a Python-friendly interface on top of the API and makes common automation tasks much easier.
We have been using it for some years now as a base and added a layer with additional workflows, error handling and specific tasks for our business logic (which is of course breaking a clean wrapper implementation :D )

The current approach already provides a lot of value, especially through higher-level abstractions and convenience functions. The goal of this proposal is not to replace this approach, but to explore how it could be strengthened for the future.

## Motivation

As the FOSSology REST API continues to evolve, maintaining a manually implemented Python wrapper becomes challenging. New endpoints or API changes require additional effort to keep the wrapper synchronized with the API and for the v2 specification a lot of endpoints are still missing yet.

At the same time, the most valuable parts of `fossology-python` are not necessarily the individual endpoint mappings, but the higher-level functionality built around them:

* Python-friendly interfaces
* Workflow abstractions
* Polling helpers
* Batch operations
* Convenience methods
* Error handling and sensible defaults

## Proposal

One possible direction for the future could be to use the OpenAPI specification as the foundation for a generated low-level client, while keeping the existing Python wrapper as a high-level abstraction layer.

Conceptually:

```
OpenAPI Specification
│
▼
Generated API Client
│
▼
fossology-python High-Level Wrapper
│
▼
Applications
```

In this approach:

* The generated client would provide broad coverage of the REST API.
* The existing Python wrapper would remain the recommended user-facing interface.
* Higher-level workflows and convenience features would continue to be implemented manually.
* Users would not need to interact with generated code directly.

## Potential Benefits

Such an architecture could provide:
* Reduced maintenance effort for API endpoint coverage.
* Faster availability of newly introduced REST API functionality.
* Less repetitive wrapper code.
* Better alignment between the REST API and the Python library.
* More time for contributors to focus on higher-level features and usability improvements.
* No need for breaking changes to the existing public API.

## Possible Migration Approach

This could be introduced incrementally without replacing the current implementation:
1. Introduce a generated client internally.
2. Gradually migrate existing wrapper functionality to use the generated layer.
3. Continue building workflow-oriented functionality on top of it.
4. Keep the existing user-facing API stable.

## Discussion

This issue is intended as a discussion about the possible future direction of `fossology-python`.

The intention is of course **not** to replace the current wrapper or reduce the value of the existing implementation. Instead, the goal is to explore whether the OpenAPI specification could help reduce repetitive maintenance work while allowing the project to continue providing a clean and Pythonic experience.

Would such an architecture be a direction that the maintainers would consider for the future of `fossology-python`? Maybe it was already in your mind.

Start by reviewing the current fossology-python wrapper and the available OpenAPI specification. The issue proposes an architectural direction rather than naming files, tests, or an implementation entry point. Done would require maintainer agreement on the direction and a concrete incremental migration plan that preserves the existing user-facing API.

Written by the indexing model from the issue text.