processing of mac commands fixed

First of all I would like to say that I like this simple and clear approach very much. I think that by removing all unnecessary features the libary can become extremely efficient. Also, I think that it should meet the specifications as good as possible.

I found some bugs in the way mac commands are processed.

The first problem is that the commands are processed byte after byte without the distinction between command identifier (CID) and mac payload. For example, if Message_Control.Frame_Options is something like [0x05, 0x06, 0x84, 0x76, 0x28, 0x06]: The first byte (0x05) is the CID RXParamSetupReq and the next 4 bytes (0x06, 0x84, 0x76, 0x28) are the associated payload. The last byte (0x06) is then again a new mac command with the CID DevStatusReq. We therefore have only two mac commands.

The second bug is that the replies which are written into newoptions are overwriten if there are more than one mac command.

The third minor bug is that the length of the reply is set to Frame_Options_Lenght (so the length of the incoming mac commands, not the reply)

And the last point is not really a bug. But mac commands can also be sent as part of the payload (to port 0). In that case these commands should also be processed.

As a fix i created the function processMacCommands(...). I think this also makes it clearer how the data is processed. At the moment mac commands are mostly ignored. I have adopted the way the commands RXParamSetupReq and DevStatusReq are processed. But I think it's a good starting point to expand the handeling of the mac commands, and to fulfill more and more the specifications.