Add relative import addon.

[qeffects]

What this fixes: Relative requires in lua suffer from losing all emmylua/autogenerated annotations because Lua Language server can't follow through dynamic paths. Example:

local path = (...):gsub(".file", "")
local anotherFile = require(path..".anotherFile")

This allows for your library to work independent of what the external file system looks like, for example your library could be copy pasted in /libraries/* /libs/* /whatever/* and you could import adjacent files regardless.
But, anotherFile is now a completely unknown variable and you have to manually annotate it.

This together with https://github.com/Keyslam/LuaImport adds an import("./anotherFile") function that preserves type information from the required file.

[carsakiller]

Please run StyLua on your submodule to apply the proper code style.

[carsakiller]

Please note that plugins will not be enabled automatically by the addon manager. Users will have to manually add the path to runtime.plugin.

[qeffects]

Please note that plugins will not be enabled automatically by the addon manager. Users will have to manually add the path to runtime.plugin.

Can this be potentially circumvented by adding it to the addon config.json settings?

[carsakiller]

Probably, but that is one of the exact things I look for when checking addons for malicious code. Not saying this plugin is malicious, but the whole reason that the addon manager does not apply plugins when enabling an addon is because I don't want remote, unknown code executing on people's computers.

My plan was to pull the plugin up in VS Code for review by the user and allow enabling or ignoring the plugin, but I never got to it as I started work on a cross-editor addon manager.