feat: vendor and clean up plenary

[clason]

This started as an procrastination investigation into what we actually use from Plenary, and which part of it can easily be replaced with current Neovim API. This is obviously not ready to merge yet, but I'm putting this here in the open now that Plenary is going to be archived, in case people want to follow along (and pitch in) as I keep chipping at it.

I think I have picked all of the low-hanging fruit, but there's obviously much more to be done. Roughly in order of difficulty:

•  the class.lua module is only used in the (now renamed) async_job telescope module to define a bunch of pipes objects. These should just be created directly, but care is required to adapt the downstream usage.
• the scandir.lua is only used in one place: to list files in a directory previewer. As I don't use that myself, I have been hesitant to convert it (should be a straightforward replacement using a variant of vim.system('ls'), so that's another nice, self-contained, project). As far as I can tell, the directory preview is only used in the telescope-file-browser extension, which isn't actively maintained and arguably too far out of scope for a core extension.
• the path.lua module usages are straightforward to replace with vim.fs and vim.fn calls; there's just quite a few of them. But this can be done file by file, so it's a good "fifteen minute project" when someone is bored. A first step could also be is to just replace suitable functions with wrappers of existing (libuv or Nvim ) API and prune then-unused internal functions. EDIT: In particular, the OO wrapper should be removed and replaced by flat string manipulation functions (and moved, if necessary, to utils.lua).
• the strings.lua module now contains only a few useful utility functions; these could be moved to a stand-alone telescope.strings. (Except for dedent; that should be replaced.)
• the border.lua and popup.lua can probably stay, but should be refactored to be a single UI utility module -- possibly moved into the telescope module. (That requires a bit more knowledge about the architecture than I have.) In any case, we don't need a wrapper that is expressly designed to make Nvim floating windows look like Vim popups (just something that makes our life easier).
• the job.lua module should be replaced by vim.system; again, the deep integration makes this trickier but there should not be much feature disparity that would block this. One could start with refactoring the top utils.lua module and see where to go from there.
• the async.lua (including vararg.lua, which is only used there) and log.lua are probably the biggest modules; these will have to stay for a bit until vim.async and vim.log are done, in which case migrating to those will be a rather big (but necessary) refactor.

So the plan for this PR is:

1. Remove all usage of class, path, and scandir.
2. Clean up border/popup, job, log, async and expose them for extensions.

A follow-up PR should rewrite job as a thin wrapper over vim.system and deprecate it (log and async will get the same treatment once the corresponding upstream modules are stable).

A couple of notes:

• I am using this branch myself but can only test the features I use myself; it's quite likely I inadvertently broke some feature I don't use (and that isn't covered by tests). So I would appreciate outside testing -- you can just specify the feat/neoplen branch in your plugin spec.
• The plenary.busted and test_harness modules are no longer in-tree but moved to an external plentest.nvim module that is a test-only dependency.
• I have renamed the modules to neoplen exactly so they won't conflict with plenary installed as a dependency for an extension, but they of course will need to adapt in some way if we want to completely remove the dependency. I expect that this will involve a mix of using upstream API (for things like path) combined with simply pulling in one of the remaining neoplen modules. This is a bit tricky since I cleaned out modules that are still here, so I have probably removed functions that extensions rely on -- these will have to be added back. @delphinus
• No more FFI.

[jamestrew]

Not sure how to deal with docgen

I did make an effort to switch out the custom tree-sitter-lua based docgen for one based off of neovim core several years back. #3227

I can revive this.

[delphinus]

Thank you @clason . I almost understood and agreed the changes. I will use this branch and check extensions' behaviors.

[clason]

@jamestrew If I understand this correctly, strings.dedent is only used for docgen -- in that case, can we move this (in a simplified, less general form) into your docgen module that is used now?

[jamestrew]

@jamestrew If I understand this correctly, strings.dedent is only used for docgen -- in that case, can we move this (in a simplified, less general form) into your docgen module that is used now?

removing the ---@eval and the strings.dedent dependency here #3670