Can not analyze symbols with Chinese

[baby0o01999]

Can not analyze the Chinese function name, variable name, please add the analysis of Chinese function name and variable name support.
Luajit can support gbk or utf8 Chinese function name and variable name.

example
`
function 中文函数名(参数1,参数2)
local 中文变量 = "Chinese variable name"
end

[fstirlitz]

PUC Lua doesn't accept this code:

$ lua5.3
Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
> function 中文函数名(参数1,参数2) end
stdin:1: <name> expected near '<\228>'

$ lua5.2 
Lua 5.2.4  Copyright (C) 1994-2015 Lua.org, PUC-Rio
> function 中文函数名(参数1,参数2) end
stdin:1: <name> expected near char(228)

$ lua5.1 
Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> function 中文函数名(参数1,参数2) end
stdin:1: '<name>' expected near '�'

Aparently LuaJIT allows any octet ≥ 128 inside identifiers. (The documentation only says 'UTF-8' characters are supported, but nothing actually checks the encoding for validity, and a comment in the source code suggests that other encodings are meant to be supported as well.) That at least makes it simple to implement; I worried we might have to import the Unicode character database to check character properties or something.

Well, sort of simple, because we parse Lua source code at the level of code points, not bytes, which brings back the conundrum I've had with interpreting string literals...

Given that it's an extension from PUC Lua, I'll probably implement this, but it will require being explicitly enabled by the user, like with the luaVersion option. Please note that this is not full LuaJIT support. For example, LuaJIT will accept code like this, unless LUAJIT_ENABLE_LUA52COMPAT is defined when compiling:

goto skip
local goto = print
goto "hello"
::skip::

Supporting code like this might be too tricky to be worth it, so I explicitly don't promise that.

[fstirlitz]

Implemented in 7172940. Consider it unstable, however. I might still revisit the encoding issue.

[fstirlitz]

I filed the encoding issue as #68. Another question that remains is whether to integrate this feature into the feature flags framework (i.e. the features object) and expose the latter directly in the API. I'm leaning towards 'yes'.

[fstirlitz]

Apparently Lua 5.4 will add this feature behind a compile-time flag: lua/lua@e0ab13c. Although it seems that unlike LuaJIT only (modern) UTF-8 names will be supported.