Improve qualcomm parser

[handymenny]

This pull request contains some changes to qualcomm LTE parser, I put them in one pull request to avoid creating many, but if you like separate pull requests let me know. The commits are quite self explaintory. I want to point out that in the commit bf9decc I assumed that inverting the EARFCN was a way to calculate the uplink EARFCN. I know that the commit 5bcc03c can be a bit controversial, I had that problem with wireshark and in my opinion that change is the best way to solve it

[peremen]

As usual, thanks for your effort.

For commits cec854f to bf9decc, there were some considerations in my original design:

• Due to limitations of GSMTAP Wireshark dissector only 14 bits of *ARFCN is available. For 2G and 3G it is not a problem as DL/UL *ARFCNs are lying mostly within the similar 10000s, but LTE it is different so I used one DL EARFCN even for UL packet. Take an example of B20: DL EARFCN 6200 and corresponding UL EARFCN is 24200, then boom it is overflow.
• It is possible to have asymmetric bandwidth for DL/UL, in that case DL and UL EARFCNs are not strictly linked. For abovementioned reason I did not used UL EARFCN from QC/Samsung cell information though.

For PDCP: That was my experimental code though. Thanks for modification.

I will cherry-pick remaining commits after making my thoughts.

[handymenny]

For commits cec854f to bf9decc, there were some considerations in my original design:

* Due to limitations of GSMTAP Wireshark dissector only 14 bits of *ARFCN is available. For 2G and 3G it is not a problem as DL/UL *ARFCNs are lying mostly within the similar 10000s, but LTE it is different so I used one DL EARFCN even for UL packet. Take an example of B20: DL EARFCN 6200 and corresponding UL EARFCN is 24200, then boom it is overflow.

* It is possible to have asymmetric bandwidth for DL/UL, in that case DL and UL EARFCNs are not strictly linked. For abovementioned reason I did not used UL EARFCN from QC/Samsung cell information though.

So maybe it is better to remove the code that deals with earfcn "inversion"? If you don't do that inversion the DL earfcn is logged. My problem was that I had EARFCN 0 in DL packets. the calculation of the UL earfcn was not really necessary