Replace customWidgetMap API with plugin

[cpascual]

TaurusForm.{get,set}CustomWidgetMap API is tango-centric and it requires taurus to keep knowledge of a different project (sardana) since it maintains T_FORM_CUSTOM_WIDGET_MAP.

Fix this by switching to a plugin-based solution using entry points:

• define an entry point group called "taurus.qt.taurusform.item_factories" "taurus.form.item_factories"
• other packages (such as sardana) can then register "Taurus Value Factories" for this entry point group.
• TaurusValue factories are functions that receive a TaurusModel as their only argument and return either a TaurusValue-like instance or None in case the factory does not handle the given model.

The old CustomWidgetMap API is still kept for backwards compatibility but it is deprecated and will be removed eventually.

This PR makes #1101 obsolete

[cpascual]

TODO: document the entry point

[reszelaz]

Well, maybe better if you take a look on the travis-ci failures. Whenever you consider them satisfactory go ahead with auto-merge.

[cpascual]

Well, maybe better if you take a look on the travis-ci failures

I have being re-running the travis builds and I managed to get some of the targets to green, but IMHO it is better to merge #1109 first to get a more robust CI.

[cpascual]

Hi @reszelaz Since your review I did some heavy refactoring in this PR. would you mind looking at it again?

Basically I:

• generalized the plugin selection mechanism
• deprecated the Custom Widget API of TaurusForm, TaurusValue and TaurusGui (and made the needed changes to provide backwards compatibility without triggering deprecation warning in our internal code)
• renamed the entry point (this is because I plan to propose a simpler convention for entry point names in taurus, in the context of TEP13)
• implemented CLI options in taurus form to enable, exclude and list item factories
• allowed to configure selection of plugins via tauruscustomsettings
• implemented extensive testing (I aimed to 100% coverage of the new code)

[cpascual]

IMPORTANT: I had to allow failures in Travis for the py35-qt5 target.

Looks like something in this PR breaks this target (it is working fine e.g. in #922 ). I'll investigate it now, but I propose not to block this PR waiting for the solution, because this PR opens the door to other urgent plugin-related developments.

As a first investigation, I can mention that it is reproducible locally with Tox:

taurus(plugin_cwmap)$ tox -vv -e py35-qt5
(...)
========================================================================================= 640 passed, 5 skipped, 1 xfailed, 19 warnings in 184.89 seconds =========================================================================================
MainThread     DEBUG    2020-05-20 22:50:35,385 pyvirtualdisplay.abstractdisplay: unset DISPLAY
MainThread     DEBUG    2020-05-20 22:50:35,385 easyprocess: stopping process (pid=24767 cmd="['Xvfb', '-br', '-nolisten', 'tcp', '-screen', '0', '800x600x16', ':1001']")
MainThread     DEBUG    2020-05-20 22:50:35,385 easyprocess: process is active -> sending SIGTERM
MainThread     DEBUG    2020-05-20 22:50:35,507 easyprocess: process has ended
MainThread     DEBUG    2020-05-20 22:50:35,507 easyprocess: return code=0
MainThread     DEBUG    2020-05-20 22:50:35,510 easyprocess: stdout=
MainThread     DEBUG    2020-05-20 22:50:35,512 easyprocess: stderr=
Dummy-2        DEBUG    2020-05-20 22:50:38,715 pt168.cells.es:10000.sys/tg_test/1.throw_exception: Error trying to unsubscribe configuration events
Dummy-2        DEBUG    2020-05-20 22:50:41,916 pt168.cells.es:10000.sys/tg_test/1.state: Error trying to unsubscribe configuration events
Dummy-2        DEBUG    2020-05-20 22:50:45,118 pt168.cells.es:10000.sys/tg_test/1.state: Failed: Not able to acquire serialization (dev, class or process) monitor
Dummy-2        DEBUG    2020-05-20 22:50:45,119 TaurusPollingTimer[3000].Timer on _pollAttributes: Timer::stop()
TimerLoop 1    DEBUG    2020-05-20 22:50:45,150 TaurusPollingTimer[3000].Timer on _pollAttributes: Timer thread ending
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/home/cpascual/src/taurus/.tox/py35-qt5/lib/python3.5/site-packages/tango/device_proxy.py", line 1300, in __DeviceProxy__unsubscribe_event
    evt_info = se[event_id]
KeyError: 110

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/cpascual/src/taurus/lib/taurus/core/tango/tangoattribute.py", line 787, in _unsubscribeConfEvents
    self.__dev_hw_obj.unsubscribe_event(self.__cfg_evt_id)
  File "/home/cpascual/src/taurus/.tox/py35-qt5/lib/python3.5/site-packages/tango/green.py", line 195, in greener
    return executor.run(fn, args, kwargs, wait=wait, timeout=timeout)
  File "/home/cpascual/src/taurus/.tox/py35-qt5/lib/python3.5/site-packages/tango/green.py", line 109, in run
    return fn(*args, **kwargs)
  File "/home/cpascual/src/taurus/.tox/py35-qt5/lib/python3.5/site-packages/tango/device_proxy.py", line 1302, in __DeviceProxy__unsubscribe_event
    raise KeyError("This device proxy does not own this subscription " + str(event_id))
KeyError: 'This device proxy does not own this subscription 110'
ERROR: InvocationError for command /home/cpascual/src/taurus/.tox/py35-qt5/bin/python -m pytest lib/taurus --show-capture=no (exited with code -11 (SIGSEGV)) (exited with code -11)
py35-qt5 finish: run-test  after 206.11 seconds

I am following 2 leads:

• The version of pytango is older (9.2.5 vs 9.3.1) in the case of the failing target. My hypothesis is that either the newer python or pytango versions are more robust during process exit.
• Probably one of the new tests could be improved to clean its tango objects more gracefully and avoid triggering the bug even in the old versions

[cpascual]

Thanks @reszelaz for the review. I fixed all the doc issues that you found. I'll merge when Travis goes green