pel.c incorrect bit shift for storing send/recv packet counters

[Aznable111]

Not a major issue for usability but caused confusion when debugging using this AES implementation elsewhere.

Fixed the packet counter for HMAC-SHA1 validation to where storing each byte of the send and receive packet counters correctly do a right shift to store the most significant values into the greater positions of the array. This prevents the packet counter from looping after reaching the 256th packet.

[creaktive]

Thanks for fix @Aznable111!
Yeah, consistency with other AES implementations is great. Anyways, I was wondering, what would happen when the fixed version of tsh client tries to connect to an older version of tsh server? Or vice-versa. I suspect it would work seamlessly, since the current behavior of looping after reaching the 256th packet is not known to cause any issue.
But just wanted to check with you before merging.