Add AES support to crypto lib

[dborovcanin]

Add AES modes GCM, CBC, and CTR to the crypto library.

[dborovcanin]

@vadv @scr-oath Can you, please, take a look at this one when you find time?

[vadv]

@dborovcanin thank you, Душан!

[scr-oath]

I'm curious - doesn't Lua support binary strings? Why do we need to pass strings as hex?

[scr-oath]

Perhaps we can add the hex functions and then just pass a binary string…

[dborovcanin]

@scr-oath I used strings because of the limitations of *lua.LState - there is no such thing as l.ToBytes(1), and I'd have to work with a table and convert it to a byte slice, so hex functions would probably not help with that. Maybe adding ToBytes to the Lua lib would. I suspect lots of limitations (similar to my bits PR) come from Lua 5.1. Maybe one day, if we decide to implement Lua 5.3 or 5.4 support...

[scr-oath]

I'm not quite sure I understand - strings support binary data. take a look at the base64 stuff…

[scr@MacBook-Pro-3]$ go build ./cmd/glua-libs/...
[scr@MacBook-Pro-3]$ ./glua-libs -e 'base64 = require "base64"; io.stdout:write(base64.StdEncoding:decode_string("Zm9vAGJhcg=="))' | od -t x1c
0000000    66  6f  6f  00  62  61  72                                    
           f   o   o  \0   b   a   r                                    
0000007

I was thinking that, since you can slurp in a whole file https://www.lua.org/manual/5.1/manual.html#pdf-file:read you might want to use that - and, with this, then you have to deal with converting it to hex…

I'd rather clients could pass the binary data to it - and, if we need to add the hex go library to help with conversion, then let's do that - there's no reason to use a table - the string, itself, is not a C++ string - it supports \0 characters just fine (is more like std:string - technically, I suppose, it's a golang string but just saying… it definitely does fine with any data)

Converting to "byte slice" is simply []byte(L.CheckString(1)) or the like