Rewriting the unetsocket samples to be consistent

[notthetup]

This is the first step for re-writing the unetsocket samples to be more consistent between languages and to be able to exemplify how to use unetsocket as a library to connect to and command UnetStack.

The examples should try to be consistent in their names of the examples and the functionality they provide, and the names of input arguments, etc. The examples should also try to be idiomatic to the language they are written in to help users get started with the UnetSocket API in their preferred language. The examples should also be command-line utilities that can be used as a starting point for building your applications.

The following proposal omits any language-specific extensions for the example files and other language-specific details that might require the changing of the syntax. The following proposal defines the various sets of arguments that the examples should accept and the functionality they should provide.

The samples can be executables, in which case they should take in 2 optional command line arguments (port and ip address). In scenarios (like range) where there is a very obvious non-optional parameter (in the case of range, to), then the executable may also take the parameter as a command line argument.

More details : https://github.com/org-arl/unet/issues/1877

[mchitre]

As part of this effort, do we want to also consider updates/changes to the UnetSocket API? Specifically, to enable to socket to perform more complex operations such as sending/receiving messages, with explicitly having to refer to the underlying gateway?