refactor: remove internal implementation of util.path.dirname

[dundargoc]

Instead, just return the result of vim.fs.dirname.

[glepnir]

LGTM.. Actually it can be removed. see #3434
Although the test passed. But the test here is a bit weak. I am afraid that hasty merge will break some uses. . So it has been in draft state.

[dundargoc]

Actually it can be removed.

@justinmk pulled out a deprecation strategy in #2079 (comment), I interpret his comment to mean we shouldn't remove any functions from util yet.

[glepnir]

Yes. A safe approach :D. But I want to make lspconfig become a pure configuration collection. It would be helpful to exploit some of the functions of lspconfig step by step? If possible, is it a good idea to use deprecate here? Point to vim.fs.dirname so that any other plugins or users who use this function will remove the dependency on util.path.dirname.

[dundargoc]

Yeah, kinda agree. I've written a complaint in the issue.

[justinmk]

This is a good example of why removing util.dirname gains almost nothing. Keeping the skeleton around is low cost. Because we'll just freeze it once everything is upstreamed. And meanwhile, shrinking the actual implementation gives us a clear picture of which logic still doesn't have an upstream equivalent. The mere presence of util.dirname doesn't harm anything, though, yes, we will need to update something like .github/ci/run_sanitizer.sh to prevent future uses of util.dirname in configs.

As we hollow-out the guts of util, it will become almost empty. We can later decide whether we want to delete it entirely, and that can be done as one big "breaking" step instead of many incremental "breaking" steps.

So this is a good change, and we should continue to make this kind of change. The possible future breaking change can wait until later. There is no need to do it right now. Let's just focus on shrinking the implementation, first.

[justinmk]

a @deprecated token would help too, and the docstring can mention "use vim.fs"

done in #3462