Change the way that foreign import "string" works

[jparoz]

Instead of passing the string to require without any processing, we should:

• Require that any imported Lua files be passed (by expected filepath?) to huck
• Build a collection of all the given Lua files
• When we process e.g. foreign import path/init.lua, check each of the given Lua files to see if the end of their filepath matches the given path after foreign import
  • If there is exactly one match, give that file to loadfile (?) in the generated code
  • If there is more than one match, or zero matches, throw an error

Questions:

• Is this the best way of resolving modules?
  • Note that with loadfile, there's no way to import a Lua module written in C. This is a significant loss.
  • Maybe the best way to handle all this is just to make the user pinky swear that their environment is configured such that all needed modules will be on their package.path or package.cpath as appropriate, including compiled Huck modules; and just give the module name to require everywhere. That is, for a Lua module from file foobar.lua, the module name is foobar; for a module compiled from baz.c, the module name is baz; and for a Huck module, the module name is defined at the top of its source, e.g. module Quux; has module name Quux. Thus, if require is given the module name require("Quux"), then it should find the compiled Huck module Quux;.
    • A consequence of this is that require("Foo.Bar") to search for a Huck module Foo.Bar; will look in the filepaths Foo/Bar.lua and Foo/Bar/init.lua by default. This will have to be expected as default behaviour, and should be documented so that environments with different searchers can adjust accordingly.
• How does a user communicate that they actually need to use require, instead of loadfile?

After the above thoughts, closing in favour of #48.