Added python lib wrapping the HTTP REST interface

[favreau]

No description provided.

[rdumusc]

Looks very good in general!
A few open questions / remarks:

• In TransferFunction class, how about renaming attributes -> channel?
• I'm not a Python specialist, but for certain classes like Material, are the setters useful or could the member variables simply be public? Or is it designed so that the members look write-only..? I'm not super used to setters not beginning with set_* so I tend to confuse them with getters.
• Add unit tests for the serialization of base classes?

[favreau]

Thanks for your comments:

• Attribute vs channel was a long discussion already ;-) And channel was indeed one of the options, but we decided at the time that it was too RGBA related, and Brayns showed that other 'attributes' such as light emission are also part of the transfer function. So attribute was the winner of the long and passionate discussion :-)
• I was myself not quite confident with the implementation, and I actually started with a get_/set_ syntax but decided to go for an API that would be a setter if you specify an argument, and getter if no argument is specified. Since then, I had another look at the documentation and read a bit more about what the standards would be. In the end, Python3 appears to offer annotations such as @Property that I think I should be using. I will therefore try this implementation and update the pull request.
• Yep, unit testing... shame on me. Working on it :-)

[rdumusc]

Arghh, too bad that Attribute won the debate ;-) Channel is more accurate and not tied to RGBA IMHO.
Good for the rest!

[hernando]

Another candidate that I liked more was target.

[favreau]

I really liked channel as well, but unless we really want to go for another poll, I'll stick to attribute.

[rdumusc]

+1

[favreau]

retest this please