Class 0/1 connections require explicit state "timed out"

For CIP Safety devices, to fully satisfy the Safety Validator state machine, the CIP class 0/1 connections require a "new" state "timed out".
Technically, it exists already, but is transitive (towards state non-existent).

The EtherNet/IP Core shall be able to make this state explicit, observable by the host application and allow it to (optionally) explicitly clear the state towards non-existent.
This would allow mapping of Safety Validator State "failed" to the connection's timed out state.

• Introduce new "Timeout" state for CIP connections
• Switch to enable/disable new CIP connection state (via host API) (AutoDelete vs. ExplicitDelete)
• FwClose shall lead to "connection delete"

Development Notes:

1. Stack parameter EIP_OBJECT_PRM_POINT2POINT_IOCONNECTION_TIMEOUT_ACTION_NO_AUTODELETE was introduced.
2. New connection state EIP_CM_SAFETY_TIMEOUT was introduced
3. The feature only applies to T2O, point to point class0/1 connections, multicast connections will still auto-delete.
4. When enabled, such connections will be held in EIP_CM_SAFETY_TIMEOUT state
5. A FwClose will close the timed out connection, this FwClose is subject to FwOpen-forwarding
6. The host application will explicitly delete all timed-out connections with EIP_OBJECT_TERMINATE_CONNECTION_REQ appropriately.
   • Safety Use Case: Delete-Service of the Safety Validator will delete the connection.
7. The CONNECTION_IND packet is now synchronous for CIP class 0/1 connections, which is a significant behavior change.
   • This change was required for CTT, when the CONNECTION_IND->TERMINATE_REQ/CNF takes too long at the mailbox, the CTT fails to open the connection since it was not freed yet. As a solution, a synchronous CONNECTION_IND on ForwardOpen provides  a blocking point which ensures the ordering of packets in the mailbox: Before a new connection opens, the host application will see the timeout and will issue the terminate before continuing with the new connection open.
     This change is basically good, as it provides better consistency for the host application, but may have impact on existing applications (additional urgent CONN_IND mailbox packet for QuickConnect, changed timing). Applications that handle the connection indication properly will not experience any bad behavior due to this change.