Deprecate strLua types/option helpers

[MattSturgeon]

Why

The biggest issue with types/options that transform the value is that once implemented, we are stuck with it lest we break users configs that rely on the transformation.

The other issue is that the transformation is somewhat hidden, meaning users end up defining a config in nix that is subtly different from the lua we end up producing.

Neither of these are an issue for "normal" module options, but for rfc42 style options such as settings it is not ideal.

How

We can deprecate passing strings directly using transitionType coercion. Similar to extraFiles, we would need a transition period before eventually removing support for string definitions.

When

We should update internal uses before having a deprecation warning.

Even if we don't want to deprecate yet, replacing the option apply implementation with a coercedTo type would be a good refactor IMO.

We should consider moving to nixpkg's lib.generators.mkLuaInline too, before asking users to change their configs. See #1935

[MattSturgeon]

@nix-community/nixvim any thoughts on a plan here? I think we should go down the strLua = coercedTo str mkRaw rawLua route, and start using __raw in our defaults/examples.

However I'm hesitant to make this change if we're soon going to start recommending lib.generators.mkInlineLua instead of lib.nixvim.mkRaw (#1935). It's possible we'd instead want coercedTo str mkInlineLua inlineLuaType?

I think we should decide this soon, since as this decision is currently blocking #2007.

[khaneliman]

I would be in favor of just transitioning to the new type mentioned in #1935 instead of spending time with rawLua if we will transition away from it soon.