Proper fix for error 'object has no attribute 'getSlave' in EtherCAT extension

traceback:
File "/home/developer/WorkData/PLC/beremiz/beremiz/IDEFrame.py", line 1433, in OnPouSelectedChanged
window.RefreshView()
File "/home/developer/WorkData/PLC/beremiz/beremiz/etherlab/ConfigEditor.py", line 837, in RefreshView
self.RefreshProcessVariables()
File "/home/developer/WorkData/PLC/beremiz/beremiz/etherlab/ConfigEditor.py", line 886, in RefreshProcessVariables
slaves = self.Controler.GetSlaves(**self.CurrentNodesFilter)
File "/home/developer/WorkData/PLC/beremiz/beremiz/etherlab/EthercatMaster.py", line 341, in GetSlaves
for slave in self.Config.getConfig().getSlave():
<type 'exceptions.AttributeError'>:_'lxml.etree._Element'_object_has_no_attribute_'getSlave'

Steps to reproduce problem:

- Add new EtherCAT master
- Add new EthercatNode to the master
- double click on


Revert commit "Dirty fix for error '_object_has_no_attribute_'getSlave' in EtherCAT extension"
[a3ac46366b86a0b237dac93be6b2281ac70b98a8].

The problem was that XML elements (proxy object) in some cases were created using custom XML
classes constructors and lxml.etree.Element() call and live python
patching. This causes that lxml backend doesn't know that custom python class
should be used for these XML elements.
Proxy object can be move/deleted and recreated by lxml
backend at any point in time or this can be done in python by copy/deepcopy operations.
If this happens, then newly created
proxy elements are using default class lxml.etree._Element. And all
custom functionality is lost.

All created XML elements should be always created through corresponding
parser and class lookup callback done by lxml backend.
It's described in more details in lxml documentation:
https://lxml.de/element_classes.html

     1

IEC 61131-3

     2

===========

     3

     4

    IEC-61131 is a normative document provided by the standards organization IEC

     5

    (International Electrotechnical Commission) and describing a standard for

     6

    implementing programmable controllers.

     7

     8

     9

    The part 3 of this document (commonly named IEC 61131-3) specifies syntax and 

    10

    semantics for programming language for programmable controllers. Beremiz

    11

    implements all the languages described in this document. 

    12

    13

    14

    http://www.iec.eu

    15

    16

PLCopen TC6

    17

===========

    18

    19

    PLCopen is a vendor- and product-independent worldwide association defining

    20

    international standards for various topics related to control programming.

    21

    For this purpose, PLCopen has 6 technical committees.

    22

    23

    24

    The goal of the sixth committee (TC6) is to define a standard file format, 

    25

    based on XML, for exchanging programmables controllers programmed using 

    26

    IEC 61131-3 languages. Beremiz uses this file format for saving the PLC

    27

    programs of projects.

    28

    29

    30

    http://www.plcopen.org

    31