Make DHCP Option 61 "Client Identifier" and maximum DHCP-DISCOVER re-transmission rate configurable

1) Add new vendor specific attribute in TCP/IP Interface Object that holds the "Client Identifier" used for DHCP Option 61

• The new vendor specific attribute 768 shall be added that has the following structure:
   

  Name	Data Type	Description	Default
  Client Identifier	Struct of:
  	USINT	Number of bytes that shall be used for OPTION 61 0: Option 61 deactivated 1-48:  Option 61 activated 49-255: Reserved for future use. Indicates the number of bytes from below ARRAY that will be used for DHCP Option 61	0
  	ARRAY of 48 USINTs	DHCP Option 61 content	All zero

• The attribute itself shall NOT be supported by default. If necessary it can be enabled by the host application.
• The attribute shall be stored in remanent data (non volatile).
• The attribute shall be used to configure/activate/deactivate the DHCP Option 61 feature in the lwIP stack (relates to PSLWIP-461).
• Per default, the attribute SHALL be gettable from the network and host application (if activated, see 2nd bullet point)
• Per default, the attribute SHALL be settable from the network and host application (if activated, see 2nd bullet point)

2) Add new vendor specific attribute 769 to the TCP/IP Interface Object that holds the maximum DHCP-DISCOVER re-transmission rate.

• This new attribute serves as an interface to the TCP-Stack'S DHCP client implementation.
  It provides a means to configure the maximum DHCP DISCOVER re-transmission rate.
• Data type: USINT (8 bit)
• Range: 4 - 60 seconds
• default: 60 seconds
• The attribute shall NOT be supported by default. If necessary it can be enabled by the host application.
• The attribute shall be stored in remanent data.
• The attribute shall be settable and gettable from the network and host (if activated).

3) Handling of increasing remanent data structure:

As both new attributes will be part of the stack's remanent/configuration data structure (that includes all data from all objects), those new attributes will increase the overall size of the remanent data structure.
When a product is updated to this or a newer version of this component after the first power cycle, the stack would "see" a smaller remanent data size than expected and this would lead to the loss of the remanent data as this mismatch would bring all objects to their factory defaults.
e.g. if the device's default is DHCP and it was assigned a static IP during commissioning, the device would fall back to DHCP after the firmware update.
During a hotfix update this shall not happen!

Therefore, a mechanism must be implemented that prevents this loss of remanent/configuration data:
The firmware must be able to detect the smaller remanent data structure and must map that smaller structure to the now bigger remanent data structure.