Reducing the [possible] burden of the built-in providers related PRs

[Furkanzmc]

I don't rely on many of the built-in LSP providers, but I notice many of the PRs are related to these built-in providers. It got me thinking it might put too much burden on you to review these PRs and approve and merge them. I thought about the method vim-polyglot uses to maintain these separate ftplugins, the maintainer just keeps a list of all the language plugins and just runs a script to update the reference to those projects.

I don't know if this is even a problem, maybe it's trivial to respond to those PRs. I thought I'd share it regardless.

[jose-elias-alvarez]

Appreciate the feedback for sure! My original intention was for null-ls to provide a framework for language-specific plugins to use as a base, but as it turns out it's become mostly a repository of built-ins. I like the vim-polyglut model and it would definitely reduce the maintenance burden a bit, but null-ls built-ins are relatively simple compared to Vim syntax files, I think, and (ideally) they don't need to be updated too often. I'd also worry about plugins becoming unmaintained (not sure how polyglot handles that).

Built-in documentation was taking up a lot of time, but that's all automated now, thankfully, so the biggest burden now is handling bugs and configuration issues. I think improving documentation will make a dent there, and I'm open to hearing other ideas.