Support for base EtherNet/IP Commands and Discovering Devices

[Penlane]

Hi, this PR aims at utilizing the ENIP-side of the communication to provide nice QoL features like retrieving asset-data via EtherNet/IP or discovering several devices

Description, Motivation, and Context

The EtherNet/IP features of this library are well separated, which means we can also add more support here.

How Has This Been Tested?

The ListIdentity / ListServices commands have been tested several times on a live PLC. Same with discovery. I'd like some feedback on how much information the discovery reply should contain. Only IP/Port/Slot? Or the whole listIdentity response?

Screenshots (if appropriate):

New Style of return:

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [X] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [X] My code follows the code style of this project.
• [X] My change requires a change to the documentation. (Maybe an addition that we can discover enip-capable devices)
• [ ] I have updated the documentation accordingly.
• [ ] I have read the CONTRIBUTING document.
• [X] I have added tests to cover my changes.
• [X] All new and existing tests passed.
• [X] This is a work in progress, and I want some feedback (If yes, please mark it in the title -> e.g. [WIP] Some awesome PR title)

[jhenson29]

I would vote for the entire reply.

[Penlane]

Alright, I extended the data that gets returned by the discovery-utility and adapted the format a little. You can see the new reply in the second screenshot above. We now know which interface the discovered devices are attached to.

[cmseaton42]

I am incorporating these changes into the typescript conversion