feat: ensure plugin runtime paths are available before rocks initialises

[mrcjkb]

With this PR, rocks.nvim maintains symlinks to the plugin runtime paths in site/pack/luarocks/opt.

Because the symlinks are all in opt, they are available on the runtimepath before rocks.nvim initialises, but none of the plugin, after/plugin or ftdetect directories are sourced (rocks.nvim takes care of this for non-opt plugins).

This brings with it some nice benefits:

• People who don't use rocks-config.nvim won't encounter the footgun of not being able to call colorscheme <scheme> in their init.lua, as they might be used to from a traditional plugin manager (see Loading colorscheme (tokyonight.nvim) #212).
• autoload directories of dependencies are available on the runtimepath, which means vimscript plugins can be installed as dependencies.

Not yet implemented (TODO):

• Integration tests
• With this change, the implementation of rocks.runtime.packadd can probably be replaced by a call to Neovim's built-in packadd [needs triage].
  If this is the case, we can deprecate :Rocks packadd and require("rocks").packadd: vim.deprecate("rocks.packadd", "vim.cmd.packadd", "3.0.0", "rocks.nvim").

[github-actions]

Review Checklist

Does this PR follow the Contribution Guidelines? Following is a partial checklist:

Proper conventional commit scoping:

• For example, fix(installer): some installer bugfix

• Pull request title has the appropriate conventional commit prefix.

If applicable:

• Tested
  • Tests have been added.
  • Tested manually (steps in PR description).
• Updated documentation.

[mrcjkb]

Let's get this merged and I'll look into deprecating :Rocks packadd in another PR.

[vhyrro]

Down to deprecate packadd as well. New changes look good to me!