lib: standardize use of lib and self

[MattSturgeon]

Things done:

• Drop helpers in internal useage
• Access nixvim's lib via self
• Access the (un-extended) lib via lib

While I like the idea of having lib.nixvim access internally within our lib, keeping our lib (self) separate from the extended lib will be better in the long-term.

This is intended to simplify accessing a lib overlay without needing to first evaluate parts of our custom lib (#2328).

lib/types.nix is a bit of a special case, it isn't really part of our (lib.nixvim scoped) custom lib. Instead it is part of the lib extension overlay. Therefore we can use either strategy of passing it { lib = final; } or { lib = prev; inherit self; }. Feedback is welcome on which approach is preferred.

EDIT: the above paragraph isn't true anymore. To avoid awkward bootstrapping we now (once again) build our types internally, as lib.nixvim.types. This is still merged into lib.types in the overlay though.

[MattSturgeon]

CI failures have highlighted some cases where we use our custom types within our nixvim scoped lib.

I wonder if types should once again be built within lib.nixvim, and then this final value can be merged later in the overlay... 🤔

Another thing I'm wondering is perhaps evalNixvim should be separate to our lib.nixvim scope:

• It will be the only internal thing that needs an "extended" lib
• If we add nixpkgs.source, it'll be the only thing that needs inputs.nixvim
• If we add build.standalonePackage, it'll be the only thing that needs packages.*.man-docs
• It is normally used outside of a nixvim configuration, unlike other things in lib.nixvim