Support shell expansion of --lua-path
Currently, `--lua-path` entries must be either a path pattern with an absolute path prefix (/usr/local/share/pico8/?.lua) or a path pattern forward-relative to the file calling require() (?/?.lua). This is sufficient for users that always put their libs in a specific place or projects where all source files are in the same dir. But this puts a burden on library authors to educate users on setting the --lua-path, and doesn't make it easy to provide a portable command invocation in library documentation.

My own intuition would have been to document an invocation like this:

`p8tool build --lua-path "?;?.lua;./?.lua" --lua demos/mydemo.lua mydemo.p8`

where mydemo.lua might contain `require('somelib/foo')` and `somelib/foo.lua` is in the library's top-level alongside `demos/`. The `./?.lua` does not work as expected. If I replace it with `$PWD/?.lua` it works as intended, but this is more shell-specific and less portable.

I *think* the right solution is to shell-expand Lua path entries *only* when given with `--lua-path`. `/x/y/z/?` and `a/b/?` behave as before (absolute FS path and require-relative, respectively). `./a/b/?` would expand to an absolute FS path relative to the current working directory (equivalent to `$PWD/a/b/?` as expanded by the shell itself). I don't see a reason not to support `../a/b/?` or `~/a/b/?` (user home dir expansion) in this way when provided directly on the command line.

It's worth experimenting with the official Lua interpreter to see what it supports, and try to match.