[pkl.lua] Add `lua.Parser`

[lilyball]

This updates the pkl.lua package to have a Parser class that can parse a static subset of Lua. It's targeting the same subset of Lua that Renderer outputs (namely, a document consisting of key/value pairs consisting entirely of literals, with no expressions), though it recognizes all Lua syntax, including handling all forms of comments and literals that Renderer does not emit (such as hexadecimal floating point literals).

The parser's interface is modeled after pkl.json#Parser, though it uses the property useDynamic instead of useMapping as Lua syntax does not make a distinction between objects and arrays. Like pkl.json#Parser, path converters are run as though all string keys are properties, even when configured to return a Mapping.

In addition to adding the parser, this PR also updates Renderer to start applying converters to mapping entry keys, to match PcfRenderer's behavior. Any mapping entry key[^1] has class converters applied to it, and if the key is itself an object, nested values will be converted the same way PcfRenderer does (which is to say, any nested values have a path that starts at the object and omits the "^" marker, so e.g. a key [new Dynamic { a = 1 }] has a single nested value whose full path is "a").

This also renames LuaIdentifier, LuaKeyword, and LuaRenderDirective to drop the leading "Lua", though it leaves deprecated typealiases behind for compatibility.

This PR also bumps the project version to 1.1.0.

[^1]: Reminder that due to a language limitation, when rendering a Dynamic, any mapping entries with a String key are indistinguishable from properties.

[lilyball]

Force-push was to fix an indentation issue in the new commits.

[lilyball]

@bioball I've addressed your feedback, though I left the [\w&&\D]\w* intact in the source as expanding that to [a-zA-Z_][a-zA-Z0-9_]* negatively affected formatting of the regex comments.