Draft: 🗑️ deprecate the quiddity creation from the pyQuiddity constructor and ✨ add a quiddities descriptor for pySwitch

should close #100 (closed)

this MR is doing two things, I tried (and failed) to separate concerns:

🗑️ deprecation of the quiddity creation from the pyQuiddity constructor

it seems this was my major issue and I took the decision to remove it:

• before:
  1. py_quiddity = switcher.create(kind, nickname, config)
  2. py_quiddity = Quiddity(switcher, kind, nickname, config)
• now:

  py_quiddity = switcher.create(kind, nickname, config)
  assert isinstance(py_quiddity, Quiddity) == True
  # you can still use the Quiddity constructor but I don't recommend it
  copy = Quiddity(switcher, py_quiddity.id())

why?

• it reduces the way of creating quiddities for two methods to one
  • it could confuse user
  • it is more efforts to maintain (this mr is a proof)
• the quiddities have not the responsibilities to instantiate itself in the cpp source
  • the py API should be as close as possible to the cpp source in order to avoid frictions like #100 (closed)
• the Quiddity constructor is only used twice in exemple/tests so it doesn't seem a big deal
• this creation in the constructor lead me to a headache because I wanted to instanciate a pyQuiddity object that was already created
  • making the pyQuiddity more complex shouldn't the right direction for future maintenance

✨ add a quiddities descriptor for pySwitch

• I implemented a get_quiddities method that returns a list of all quiddities
• the quiddities descriptor is a way to get those from a property
  • it also allows us to provide extra feature in order to easily query quiddities without extra cpp methods

vid_quids = [quid for switcher.quiddities if quid.kind() is 'videotestsrc']