Use builder pattern to construct Add Plugin recipe visitors

````
─── src/main/java/com/canonical/devpackspring/rewrite/visitors/KotlinAddPluginVisitor.java:42-43 ───
[maintainability · low] The `AddPluginVisitorSupport` constructor takes 9 positional parameters, 7
of which are Strings/booleans of easily-confusable types (pluginName, pluginVersion, buildFileName,
and three template strings). At this call site it's easy to accidentally swap e.g.
`PLUGIN_TEMPLATE_KOTLIN` with `BUILT_IN_TEMPLATE_KOTLIN`, or the build file name with a template,
and the compiler won't catch it. Consider introducing a small parameter object or builder (e.g.
`AddPluginVisitorSupport.builder().plugin(...).templates(...).operations(...)`) so each argument is
named at the call site and mis-ordering is impossible.

- this.support = new AddPluginVisitorSupport<>(pluginName, pluginVersion, subprojects, parser, "build.gradle.kts",
- PLUGIN_TEMPLATE_KOTLIN, BUILT_IN_TEMPLATE_KOTLIN, SUBPROJECTS_TEMPLATE_KOTLIN, new KotlinOperations());
+ this.support = AddPluginVisitorSupport.builder()
+ .plugin(pluginName, pluginVersion)
+ .subprojects(subprojects)
+ .parser(parser)
+ .buildFileName("build.gradle.kts")
+ .templates(PLUGIN_TEMPLATE_KOTLIN, BUILT_IN_TEMPLATE_KOTLIN, SUBPROJECTS_TEMPLATE_KOTLIN)
+ .operations(new KotlinOperations())
+ .build();

````

Start with src/main/java/com/canonical/devpackspring/rewrite/visitors/KotlinAddPluginVisitor.java around lines 42-43 and inspect AddPluginVisitorSupport's constructor and its other call sites. Introduce the named construction approach described in the issue, update the recipe visitors that use the constructor, and verify the project still compiles.

Written by the indexing model from the issue text.