Apart of other  housekeeping tasks, the main modification has been done on 'transmit_buffer'.

'transmit_buffer' (used by UART) managed a dynamic memory and the transmition order of the prioritized
packets that it contained.

FILES AFECTED:
Now this 'transmit_buffer' has been splitted into 'transmit_queue' and 'dynamic_buffer'.
- 'transmit_queue' manages the order of prioritized pointers.
- 'dynamic_buffer' manages a dynamic memory space.
Also 'uart' has been modified in order to operate exchanging transactions.

BEHAVIOR:
Now UART manages a 'transmit_queue' and there is a stand alone 'dynamic_buffer' accessed by both
UART and downlink messages.

In order to exchange information UART and downlink use transaction structs (containing message address,
length and callback). Thus, uart's 'transmit_queue' actually stores transactions that refer to messages.
Both transaction and message are stored in the dymanic memory.

As said, information is exchanged through the 'dynamic_buffer', but communication is through the
general 'device' definition. This 'device' incorporates both inline and non-inline functions, what
is going to be useful in order to optimize the code execution. That is:
- messages can be generated as macros. Then, device is introduced by preprocessor and the specific
  inline function can be pasted during macro decoding.
- messages can be generated as functions, too. Then, device becomes a parameter and the function
  will depend on the device at each execution. This has two benefits: first, device can be dinamically
  changed during execution. Second, debugging becomes easier. However, execution is slower.

TO DO:
- Develop transport layers for the new message procedure (for the moment just Paparazzi transport works).

- Develop other devices (as SPI, I2C, etc.) under the general device definition.

- Develop Uplink in the same way than the new downlink.
Downlink transport layer XBee developed (but not tested yet).
UART downlink device (struct device dev_UARTx) has been moved to uart.c and
renamed as 'struct device dl_UARTx'.

Other:
- API for downlink device (device.h) has been moved to 'sw/airbone/subsystems/datalink'
- 'transmit_buffer' files have been deleted (they were not used).
- 'device_uart.c' has been deleted (no longer required).
- 'device_simUart.h' has been added.
UART driver simplified.

In order to create downlink as fast as possible without macros, a big set of functions
had been created in for each uart in 'uart.c'.
However, this set of functions made difficult to maintain the driver. Instead, just
general functions have been left and the particular uart is passed as a parameter in every execution.

Transport layers Paparazzi and Xbee have also been modified in order to follow the same procedure
(in this case there are no noticeable changes).
Included serialize and deserialize downlink data functions.
Uplink modified (no compiling errors but not tested yet).

Now there is a 'datalink' structure that manages links between the Rx devices and
their associated transport layers.
In addition, transport layers now store callback functions to be executed in case
a message is found.
Included traces into datalink and a name space into transport and uart.
(name space already existed into uart but was not used).

simUart has been remodeled.
Telemetry code structure has been successfully remodeled.

However:
- It works under a general device interface called 'device'. For the moment
  there is just link between 'device' <--> 'uart'. It has to be done in the
  same way for 'spi', 'i2c'...
- It works under a general transport called 'transport2'. For the moment
  it only exists Paparazzi and XBee transport implementation on 'tranport2'.
- 'dl_msg' function can parse just on message each time. Until now tranport layers stopped
  when a message was found (setting a flag). Now transport layers cannot be stopped and
  'dl_msg' has to be called "on time". Thus, at every call transport layer stays on stack...
  Is this a stack abuse?...
- In Dynamic Buffer there is management data in the user's Data Memory Space, DMS,
  (a mem header in each assigned mem slot). A small change could be done in order to remove
  management data from user's DMS.
  Now damage can be easily caused by user if he directly writes on memory without use of
  'write' function. 'Write' function prevends user from writing out of its assigned slot
  in DMS. Wild accesses can damage data integrity in DMS, what could potentially cause
  Dynamic Buffer malfunction.
... just few variable names modified...
included macros option for downlink (faster).

Just modifying parameter 'function_type' as 'MACROS' or 'FUNCTIONS' in gen_downlink_macros.ml,
downlink can be created as a set of macros or static inline functions.

Downlink using static inline functions works with device and transport struct pointers that
contain pointers to their API functions, thus 4 jumps in memory are required (2-go and 2-back) per
action. Every message sent requires 3 device actions and 2 tranport actions.
The benefit is not much important but is there... (Downlink by macros was the original procedure).
Time consuming should be analized.