When delete a element that depens of a motor group a better message for the user is printed.

now it takes into account if the listeners are from an object instance

- Dereference weakrefs stored in PoolBaseChannel._pseudo_elements.
- Fix PoolBaseChannel.remove_pseudo_element()
- Fix docstring of PoolBaseChannel.get_pseudo_elements()

Performing more tests revealed that these references are not problematic
in order to remove the pseudocounter core object correctly.
Finally do not delete them.

Seems like PyTango/Tango keeps alive Device objects after deleting them
(to be verified). These objects keep reference to the Sardana core objects,
making it impossible to delete them and affecting the dependency relations.
Delete reference to the motor_group in order to avoid this problem.

"head" kwarg is not used by the acquisition actions and it ends up as strong reference in the
acquisition sub-actions. This leads to a cycle reference of the measurement group
and the acquisition actions causing problems when discovering dependent elements
when deleting an element.

Measurement group becomes an operator of the controller during an acquisition and remains
as operator after. This creates an additional strong reference to the measurement group
making it impossible to really delete causing troubles when discovering dependent elements
on an element deletion. Use weakref.ref instead.

When deleting element, no dependent element can exist.
First delete pseudo element and pseudo controller, and then the physical ones.

When deleting an element no dependent elements can exist. Delete the motor groups
before the physical motors are deleted.

Pseudo counters must have cycle references with physical elements.
This causes problems when deleting elements after prior deletion of pseudo counters.
This was discovered with the following tests:
- sardana/macroserver/macros/test/test_scanct.py::AscanctTest::test_ascanct_macro_runs_4
- sardana/macroserver/macros/test/test_scanct.py::AscanctTest::test_ascanct_macro_stops
- sardana/macroserver/macros/test/test_scanct.py::A2scanctTest::test_a2scanct_macro_runs
- sardana/macroserver/macros/test/test_scanct.py::MeshctTest::test_meshct_macro_runs
- sardana/tango/pool/test/test_measurementgroup.py::TangoAcquisitionTestCase::test_meas_cont_acquisition_2
- sardana/tango/pool/test/test_measurementgroup.py::TangoAcquisitionTestCase::test_stop_meas_cont_acquisition_3
- sardana/taurus/core/tango/sardana/test/test_measgrpstress.py::TestStressMeasurementGroup::test_stress_count_2
- sardana/taurus/core/tango/sardana/test/test_measgrpstress.py::TestStressMeasurementGroup::test_stress_count_3
- sardana/taurus/core/tango/sardana/test/test_measgrpstress.py::TestStressMeasurementGroup::test_stress_count_4
- sardana/taurus/core/tango/sardana/test/test_measgrpstress.py::TestStressMeasurementGroup::test_stress_count_6

Force gc.collect() to avoid this problem.

get_dependent_elements() returns only element name. Change the return
value to return the dependent elements objects in order to extend
use cases of this method e.g. allow to check the type of the returned
dependent elements.

gc.collect() workaround is tried if any kind of dependent element
resides in the pool. Call it only in the case of pseudo counters.

Disabled channels in the measurement group are
considered as not members of the group. They neither appear
in "element list" attribute nor the measurement group listens to their events.
Hence it is possible to undefine an experimental channel which is disabled.
This may lead to a situation when we try to enable again an undefined channel.
Consider this case by not accepting a configuration which contains
an undefined element. Also allow to acquire with a measurement group which
contains and undefined and disabled channel.

PoolElement implements get_dependent_elements() and
has_dependent_elements() while PoolBaseElement only implements
get_dependent_elements(). Implement has_dependent_elements() also
for the PoolBaseElement to be able to use both methods on any type of
Sardana element.

cycle-reference may exist between an element and a traceback
stored in SardanaValue or SardanaAttribute as a consequence of
getting sys.exc_info(). Keeping a list of dependent elements in the
scope of delete_element() makes it impossible to gc.collect() to
collect the cycled objects. Use has_dependent_elements() in order
to determine if there are dependent elements and then call the
gc.collect(). Also, do not call it conditionally only for the pseudo counters
but for any element type - the cycle may be created for between any
alement and a traceback.