Add documentation for the plugin environment

Plugins have a surprisingly large amount of flexibility when the surrounding environment is considered. Unfortunately, most of the environment is undocumented, which means there's a good chance plugin developers don't know how much their plugin can really do.

Currently, printing out package.path and package.cpath gives these directories

package.path

# directories provided by the extension
$LSP/script/?.lua
$LSP/script/?/init.lua

# access to the plugin's directory
$PLUGIN/?.lua

package.cpath

$LSP/bin/?.dll

where:

• $LSP is the path to this project's folder, and
• $PLUGIN is a path to the plugin's current directory. ~/project/config/plugin.lua would make $PLUGIN point to ~/project/config

Along with giving plugins the ability to have sub-modules, the LSP has some very useful utilities in its script folder like:

• vm for inspecting types (or so it seems)
• parser.compile for getting an AST
• inspect which looks like kikito/inspect.lua
• config for reading LSP settings like Lua.runtime.version

I don't work with Visual Studio enough to understand the DLLs in $LSP/bin, or at least not enough to work with them in Lua.

... has some useful information too.

local inspect = require("inspect")

print(inspect({ ... }))
--[[--> 
{ 
  <function 1>,                   -- this plugin loaded as a chunk using `load()`
  "file:///$WORKSPACE_FOLDER",    -- a URI pointing to the workspace folder
  {}                              -- arguments provided by the setting `Lua.runtime.pluginArgs`
}
]]

I think this information is useful enough to be documented in the wiki. I can contribute to it if need be.

It would be even more useful and accessible if there was a meta-addon that adds the $LSP/script directory to Lua.workspace.library or a boolean option that adds the directory internally. I can try to contribute to that as well.

I understand that $LSP/script may be updated often for bugfixes and other things. If this is the case, I think it would at least be useful to provide a directory for plugin utilities.

I'm not sure about what to do when the VS Code extension gets updated since it changes directory. Maybe, more generally, the LSP can warn you about missing libraries.

Also, if $LSP/script updates too frequently to be mentioned in the wiki, I think the meta-addon route would be more fruitful.

Start by reviewing the plugin environment details in the issue, including package.path, package.cpath, the $LSP/script utilities, and the plugin arguments passed through .... Confirm which behavior is stable enough to document in the wiki, then make the environment and available utilities clear to plugin authors without relying on speculative DLL or meta-addon changes.