Fix: Use sw360python's batch method to restore project mainline states

[SUMITKC1]

Replaces per-release update loop with sw360python's update_project_release_relationships_batch() method to reduce API calls and follow project guidelines.

🛠 Problem

The previous implementation in update_project() restored mainline states one by one using update_project_release_relationship(...). This caused excessive API calls and potential rate-limit issues when updating large projects.

✅ Solution

• Replaced the loop with the official update_project_release_relationships_batch() method from the sw360python library (v1.9.0).
• This method allows batch restoration of all mainline states using a single API call, improving performance and aligning with the expectations outlined in issue avoid "Restoring original project mainline states" during "project update" #122 and comments from @gernot-h.

📦 File Updated

• capycli/project/create_project.py

🧪 Testing

Tested on SW360 instance https://sw360.example.com
Version: 13.1
UI: New UI
The batch update executed successfully and restored all mainline states without triggering API rate limits.

---

Let me know if you'd like me to further align the logging format or add a test scenario. 🚀

[gernot-h]

@SUMITKC1, thanks again for your effort to contribute, but it really doesn't help much if you send untested changes and don't follow the paths we discussed.

I asked you in #137 to not keep creating new PRs as this will spam the mailboxes of the maintainers and we loose track which activity belongs to which task.

And as the method name you try to call here doesn't seem to even exist, I assume you never tested this change. If you want to contribute to this project, please:

• Be sure you have a local environment where you can run the code, think about real-world examples and test them.
• Be sure that you run the test suite (poetry run pytest) after you made your changes and also extend or modify test-cases so your changes are covered.
• Try to keep changes minimal and focused. Only add or change output if it's useful for the user or reflects a major internal change.

[gernot-h]

Don't get me wrong, we really appreciate if you take the time to contribute to this project! But in the end, this only makes sense if you have a running environment so you can test your changes on real-world examples and take the time to try to follow our best practices and contribute changes you understand and tested well. Otherwise, it just consumes more of your and our time than if we would make the changes by ourselves.

So I think for a smooth start, it might be better if you concentrate on changes and improvements which are closely related to your own usage of CaPyCli, so that we know that you actually use your own code and have a first-hand understanding of the consequences of changes, instead of trying to address all open issues or results from code quality tools which don't really relate to your own usage scenarios.