Assumes that AF_INET is defined as 2

The ENIP spec (The CIP Networks Library Volume 2 (Edition 1.33), Table 2-4.4 CIP Identity Item) requires that:

> `sin_family`: Shall be AF_INET = 2. This field shall be sent in big endian order.

The mention of `AF_INET` here is a red herring; since this is a network protocol, the name of the C library constant is irrelevant, it's the value `2` that counts. Still OpENer simply fills the protocol field with the value of the C standard library `AF_INET` constant, whose value is implementation-defined (that's why there's a constant definition for it) - for example, zephyr defines it as `1`. This obviously breaks recipients who actually check the value of `sin_family`, which includes but is probably not limited to Allen-Bradley ControlLogix PLCs.

As a quick fix for this I modified https://github.com/EIPStackGroup/OpENer/blob/db1d6bfbd6cdc216944e03326167c19a5ff675d0/source/src/enet_encap/endianconv.c#L205 and https://github.com/EIPStackGroup/OpENer/blob/db1d6bfbd6cdc216944e03326167c19a5ff675d0/source/src/enet_encap/endianconv.c#L212 to instead use a constant that is always defined as `2`. A proper solution would be:
1. auditing the entire stack for uses of implementation-defined constants in protocol fields
2. fixing the stack to actually use the value of `SocketAddressInfoItem.sin_family` as set e.g. here: https://github.com/EIPStackGroup/OpENer/blob/db1d6bfbd6cdc216944e03326167c19a5ff675d0/source/src/cip/cipioconnection.c#L600
I spent a while scratching my head as to why my changes to those values weren't changing what I'm seeing on the network; they're never actually read as far as I can tell.