Modified datalink behaviour (actually, back to original procedure: ONE transport per device)

Now device stores its linked transport (in future this can become and array).
Transport also stores its linked device. This is only used during a 'device <--> transport' link
registration in order to avoid a re-association of a transport already linked to someone else.

TODO:
- Solve Downlink problem. There is padding in every 'downlink_data_xxx' struct and it is copied to
transmition buffer by memcpy. Buffer must be filled in a different way.
- Redefine device_simUart. Actually there must be a simUart (nothing to do with device!!).
- Redefine precompilation directives related with Downlink/Datalink and their associated Tranport/Device.
Downlink 'Padding Problem' solved.

Since downlink data structs are not size ordered (data with more bytes should be first)
there is padding between data fields and structs cannot not simply be moved to transmition
buffer by memcpy.

Problem has been fixed by adding a padding detector in the downlink 'message_data' file generator.
In case padding is detected in a struct, data is moved to buffer byte per byte. If a struct
has no padding, copy is still done by memcpy (faster).
removed padding problems from downlink encode function and some makefile modifications
XBEE transport finished (not tested yet).

XBEE transport configures its associated device. It is still done in same way but
using general device definition.
However, device configuration settings should not be part of transport layer!!!!
XBEE works (transmition - reception). Configuration not tested yet.

However:
1- XBee configuration starts assuming that device is set to a given baudrate.
   However, this initial baudrate is not set...
2- XBee transmition-reception description from 'xbee.h' seems not macth...

OTHER:
3- There are still problems with includes depending on firmware makefile definition
   and compilation target.
Code cleaning...