Limit ftplugin to buffer and avoid early lua requires

[Slotos]

This changes ftplugin behaviour to:

• create user commands confined to the buffer it was triggered on
• avoid filesystem lookups of require (they add up) by postponing
  them until user command gets invoked
• skip loading if it has already been executed in a buffer

To deduplicate ftplugins, lua's dofile is used to load a specific
file that holds all shared commands. This is equivalent to vimscript
standard source approach.

These make ftplugin portion of this plugin behave like a good neighbor
ftplugin - its changes are buffer local, as it's invoked when a buffer
filetype matches.

Additionally, ftplugins now read global disable_typescript_tools
variable, returning early if it's set. Not a common behaviour for
ftplugins in general, but a good way to give users fine control over
plugin behaviour nonetheless.

Not tackled is cleanup in case buffer filetype changes without reloading.
I don't think routines for that currently exists, in fact.

Additional housekeeping

• ci: use actions/cache@v3 in tests workflow

• fix: use non-deprecated iter_matches with all=true

  This fixes nightly test failures. This also changes behaviour in complex
  scenarios most likely, as instead of matching just the last node, we now
  consider all nodes in the match.

[shofel]

@Slotos Can you please elaborate on the reason why dofile is preferable over require here?

As I see, only

avoid filesystem lookups of require

is attributed to dofile. The rest goodness comes independent of dofile.

And also:

• require will search the path only once
• then the module will be cached. And require saves up on parsing
  from :help require:

The function starts by looking into the package.loaded table to determine whether {modname} is already loaded. If it is, then require returns the value stored atpackage.loaded[modname].

Disclaimer. I can`t make this merging faster. I'm just curious :)

[Slotos]

On the first call for each unique argument, require performs a lookup across a set of directories. This in itself can add up if multiple plugins use require eagerly. However, every plugin adds a lookup directory to the list, increasing average cost of initial requires. Postponing requires until the user command is invoked spreads this impact, and avoids it entirely if user doesn’t use true commands that need to require some code.

dofile loads a specific file, avoiding filesystem lookup cost.

But, your quote on require cache shows that I missed an easy and quite important optimization - the file only needs to be loaded once per ftplugin. I should cache the loads.

I’ll push an update in a few hours.

[shofel]

However, every plugin adds a lookup directory to the list, increasing average cost of initial requires

@Slotos Every plugin adds a directory to lookup, I agree. But isn't it just by the existence of the directory in packpath, and irrelated to any calls to require?

So, by adding a cache you made the solution even closer to require, and increased complexity. But what is the upside? How much and how exactly it'll be worse to use require here? 🤔