Not setting the network interface down on a regular basis

This is buggy in trunk and prereleases: Changes of TCP attribute 3 and 5 should not take immediate effect unless the object is already started!

Also, when we are configured for DHCP and do a CIP Reset type 0, we still set the interface down in the meantime. This should be avoided. If we are at DHCP and perform a CIP reset, we should still do the DHCP cycle with the netif still be set to "up". If another IP address is received from the DHCP server, we have to take it over, which will set the netif down& up again. If the IP address does not change, the netif can be kept up without interruption.

lwIP-DHCP has states renew and rebind for this, which are already implemented & active (if the server assigns renew and/or rebind timeouts). In fact the lwIP allows this, it is a valid, although this case seems not be cleanly implemented currently. Anyway, DHCP "Renew" cycles and setting the netif down/up should be (are) orthogonal concepts.

Of course, if the renew fails, the DHCP client shall transist back to rebind state and then to discover state and eventually release the IP address, which would cause the netIf to be set down.

This change is done in conjunction with changes in lwIp and its API.

Proposal for requirements:

1. The EIP stack shall execute ACD only in case the netif is actually assigned a new (== different) address (IP/Netmask/Gateway) or in case the configuration mode (ConfigControl: STATIC, DHCP, BOOTP) of the netif changes.
   1. An IP address that was already in use before will not be ACD-probed again, except if it was acquired through a different configuration method.
2. The EIP stack shall only assign a new configuration to the netif, in case it's current configuration deviates from the new configuration.
   1. Unneccesary modifications shall be avoided
   2. To detect a deviation, the current netif config shall be read & compared to, since there may be other components directly writing to the netif configuration
3. The EIP stack shall only modify the netif configuration if the TCP object is already started (on the fly) or on object start (takeover). While not started, new values are just set into the attributes (to be applied on the next start).
4. The EIP stack shall derive each new netif configuration from the attribute values ConfigControl, AcdEnable, and NetworkInterfaceConfig and the current configuration as follows:
   1. On deviation of ConfigControl, the netif shall be reconfigured
   2. On deviation of AcdEnable, the netif shall be reconfigured
   3. If ConfigControl is set to "static ip", on deviation of NetworkInterfaceConfig, the netif shall be reconfigured.
5. When deriving a new config, if ConfigControl is BOOT or DHCP, and the netif is already in the requested configuration mode, a DHCP/BOOTP renew cycle shall be triggered.
   1. The netif shall remain up and running with the previous address during that renew
   2. If the Renew causes an IP address change, the new address will be applied and all registrants will know via the netif status callback (down & up)
   3. If the Renew fails (because the server is not reachable anymore), the DHCP state machine will fall back to rebind from  any server, and if this also fails, it will set the netif down and will restart discovery. Again, all registrants will know via the netif status callback.
6. DHCP/BOOTP state machines shall be stopped while the object is not started.
   1. During BusOff, the DHCP client shall not execute on behalf of EIP.
7. When the new network link is (re)established, and the network interface is set to DHCP/BOOTP mode, a new DHCP discovery shall start
   1. If ACD is enabled, the discovery shall start with source IP 0.0.0.0 and the netif set down
   2. If ACD is disabled, the discovery shall start regardless of the current netif IP address and running status