Better `package` option helpers

[MattSturgeon]

I'd like to achieve two things here:

• mkPackageOption helper with defaultText #1950
• lazy evaluation of the default

The first point should be achieved by providing the helper with a "pkgs path" that can be used with getAttrByPath and also concatStringsSep "." to provide default and defaultText respectively.

I'm not sure about the second point. Maybe we'd need a different type that is lazier, although this may break things like mkIf.

Or maybe we can do something like either package (functionTo package) and provide a lazy function that returns the package as the default?

[MattSturgeon]

I wonder if the option default would be lazy if we didn't evaluate the default package's meta.homepage? Although, maybe that's only evaluated when rendering the docs?

[MattSturgeon]

As I understand it, meta.nixvimInfo.url usually depends on evaluating the package, however this will only be evaluated when building the docs.

Therefore, the main blocker to making package-type option defaults "lazy" is either not including the docs in the final build or not having meta.nixvimInfo.url default to the <pkg>.meta.homepage and instead always set url to a string literal...

The only thing I'm confused about, is when including the man-docs, we include the package from our flake outputs. It's probably better practice to build the docs using the pkgs available in the module eval (see #2186), however using the flake output should mean that mismatched pkgs channel errors are not possible, unless the flake inputs are overridden using follows...

[MattSturgeon]

I wonder if its enough to not avoid evaluating the package defaults, but instead allow them to fail gracefully.

We could probably just wrap the package.default.meta.homepage in tryEval.

We'd still want to check that plugins have a valid url on our nixpkgs lock, but this could be done in a new test instead of during module eval.