feat: add more plugin spec fields

[nekowinston]

Hi again 👋
Sorry about never finishing #3, I didn't have a reason to use any extra Python deps myself since drafting that PR.

This PR adds enabled, dev, cmd, main to the plugin spec,
and changes how keys are handled, using mkLuaInline:

Also implements dev by prepending dir with cfg.settings.dev.path. I ended up using this on my fork of neovim.nix, because Lazy apparently prefers the manually set dir over dev, at least for me.

I've also been trying to implement #6, I'll comment on that issue to clarify a few things.

[willruggiano]

This looks great. I'll take a closer look this week hopefully. One comment from my brief first pass is that you shouldn't have to change anything related to keys. Since we're just inheriting it as is and subsequently passing that to the Lua generator, you should be able to call mkLuaInline from your side. There may be something I'm missing though... again first pass was brief :)

This goes for anything that neovim.nix calls mkLuaInline on. IMO we shouldn't do that. Let the user do that if they wish.

[nekowinston]

the reason for opting for a mkLuaLine string in keys, is I'm not sure if there are ways to express

{ "key", "<Cmd>Command<CR>", desc = "foo" }

or

{
  "key",
  function()
    require("foo").bar()
  end, 
  mode = {"n", "v"},
  desc = "foo"
}

in Nix, since that would require lambdas (generators.toLua: type lambda is unsupported), or unnamed attrs for lhs/rhs of LazyKeySpec.

We could of course support Nix -> Lua for just {lhs, rhs} mappings, so maybe allowing str and a simple list of str?