Networking: Get rid of g_ipv4_allzeroaddr and g_ipv4_alloneaddr.  It is more efficient and more intuitive to use INADDR_ANY and INADDR_BROADCAST

Conflicts:
	nuttx/ChangeLog

STM32 F4 Discovery: Move up_cxxinitialize from nuttx/configs/stm32f4discovery/src to apps/platform/stm32f4discovery where it belongs.

Conflicts:
	nuttx/ChangeLog

Networking: setsockopt() fails when setting timeouts to values less that an 100 msec.  That is because the timeout is limited to stops of 1 decisecond and because the conversion of structure timeval was truncating the microsecond remainder.  The utility net_timeval2dsec now accespts and option to determin how it handles the remainder:  truncate, discarding the remainder, use the remainder to round to the closed decisecond value, or use any non-zero remainder to the next larger whole decisecond value.

For the setsockopt() case, it will always use the final option.  This means that a time of zero (i.e., not timeout) can only occur if the value zero was explicated provided to setsockopt().

Conflicts:
	nuttx/net/devif/devif_callback.c

Conflicts:
	nuttx/ChangeLog

Networking: Modify event list handling:  Now there are two event lists each device structure:  (1) One is for ARP and ICMP data related evetns, the other is for device related events.  Callback allocation/free routines no accept a device paramter as well as a list: If the device paramter is added, then the callback goes into both the connection-related liast AND the device event list.  Thus each socket type can received both custom data-related events as well as common device related events.

net_startmonitor.c always returned zero.  In the case where a socket has already been closed, it correctly handled the disconnetion event but still returned OK.  Returning OK causes the callers of net_startmonitor to assume that the connection was okay, undoing the good things that net_startmonitor did and causing the socket to be marked as connected.  This behavior was noted by Pelle Windestam.

Networking:  Fixes an important TCP bug: 16-bit flags was being converted to 8-bits in a few locations, causing loss of status indications

Networking:  No that ARP, ICMP, and ICMPv6 reside in the same list we need to make the definitions of ARP_POLL, ICMP_POLL, and ICMPv6_POLL different because there are small differences in the context for each.