fix: include new plugin behaviour in detection list

[zachdaniel]

The plugin module was renamed from ElixirSense.Plugin to ElixirLS.LanguageServer.Plugin, to ElixirSense.Providers.Plugin (both renames broke spark's plugin, not a big deal but if you can try not to rename those modules w/o letting me know so I can get ahead of it w/ a release of spark, that would be great.)

However, the new behaviour module is not in the list used to detect a plugin, so I have to use a behaviour that doesn't exist.

Additionally, module attributes from .module_info that are persisted appear (or can appear) as lists, and so we need to update the way we check for those flags.

This stuff has a lot of cruft, and I fully understand if we need to change it in the future, and I'm happy to participate in whatever changes we want to make. I know that there are likely changes coming to language servers soon, my only request is that I'm given a chance to justify the plugin logic's existence. It truly is a huge quality of life improvement for Ash users :)

[lukaszsamson]

While I'm OK with merging that, for the future we need to think about better separating elixir_sense and the new language server from plugins. Currently when elixir_sense loads ash plugins that depend on a behaviour defined in elixir_sense it usually leads to broken server state. Loading the plugin purges and reloads elixir_sense modules from a different version and after that all request fail due to missing struct fields or functions. I've seen countless crash logs related to ash. I think we need to design a stable interface and make it a separate library.

[zachdaniel]

I'm curious why loading the plugin does that? It would make sense for it to do that while I'm developing on spark because we have a dev dependency on elixir_sense so we can test. But for other users, who don't have a dev dependency on elixir_sense, why would loading the Spark plugin cause that behavior?

Regardless, I completely agree that this should be rethought. I don't know about separating it from the language server entirely, though. Especially given that the new LS would be "the Elixir standard LS", meaning that whatever it defines is the interface for a plugin would be the only interface for a language server plugin that matters.

[zachdaniel]

Is it possible that the logs you see are just from when I'm working on spark and so have a dev dependency on elixir_sense that differs from what the LS has? We also (a very very long time ago) instructed users to add a dev dependency on elixir_sense. That is not necessary any more. So perhaps those users could also be generating crashes in your logs?

[lukaszsamson]

So perhaps those users could also be generating crashes in your logs?

It's possible.