wip: refactor came to use properties

[SMoraisAnsys]

Description

This is a DRAFT to show how the code base COULD be refactored to leverage properties and propose an API that might be more user friendly. This is clearly subjective and I might have missed some of the required changes but it would at least give a good idea of how to do things.

The main idea is that we:

• no longer use fluent API and work with python properties (setter and getter here);
• allow users to work with more classes, e.g. I've extracted every class embedded in the definition of Camera into public classes.

Note that the changes imply that:

• the new public classes can't be directly instantiated as they require inner/kernel information that users shouldn't be aware of;
• to create an instance of the new public class, one has to use _create() where kernel information is automatically propagated;
• the coupling between classes is still present, e.g. to create a Photometric I need a Camera instance, to create a Color I need a Photometric instance, ...

Those changes are just a draft of what we could do and I didn't touch the BaseSensor or WavelengthsRange which should also be updated.

Do you see any limitations or side effects about the current changes ?

Issue linked

None

Checklist

• I have tested my changes locally.
• I have added necessary documentation or updated existing documentation.
• I have followed the coding style guidelines of this project.
• I have added appropriate tests (unit, integration, system).
• I have reviewed my changes before submitting this pull request.
• I have linked the issue or issues that are solved by the PR if any.
• I have assigned this PR to myself.
• I have made sure that the title of my PR follows Conventional commits style (e.g. feat: add optical property)
• I have agreed with the Contributor License Agreement (CLA).