codegen-java: Support not annotating constructor parameters

[odenix]

Motivation:
Spring Boot configuration classes neither require nor benefit from annotating constructor parameters with their name. The same is true for pkl-config-java configuration classes compiled with -parameter.

Changes:

• add a noParamsAnnotation parameter to CLI, Gradle plugin, CliJavaCodeGeneratorOptions, and JavaCodegenOptions
• default to annotating constructor parameters unless generateSpringBootConfig is set
• fail if both paramsAnnotation and noParamsAnnotation are set
• add tests
• update docs

Result:
Generated code does not contain unnecessary annotations.

[bioball]

LGTM; makes sense!

Looking for at least one more thumb from @stackoverflow or @holzensp.

[bioball]

Thanks for filling these in!

[bioball]

Would be good to add a blurb explaining how to use this. Same blurb should be copied to the pkl-gradle docs

Suggested change

	Default: (flag not set unless `--generate-spring-boot` is set) +
	Flag that indicates not to annotate constructor parameters with their name. +
	This option cannot be combined with `--params-annotation`.
	Default: (flag not set unless `--generate-spring-boot` is set) +
	Flag that indicates not to annotate constructor parameters with their name. +
	This option cannot be combined with `--params-annotation`.
	If `true`, requires that Java is compiled with the `-parameters` flag, or that `-generate-spring-boot` is set, and classes are loaded by Spring Boot.

[odenix]

Today I discovered a valid reason not to generate @NonNull annotations, which begs the question if multiple --no- flags/APIs are the right solution.

My original attempt was to change paramsAnnotation = null to mean "no annotation" and set the default paramsAnnotation = "org.pkl.config.java.mapper.Named". However, I discovered a few downsides of this approach:

• the default logic has to be duplicated in every layer (CLI/Gradle/CliGenerator/Generator)
• --params-annotation=null isn't great (perhaps --params-annotation= could work?)
• explicitly setting paramsAnnotation = null changes meaning (breaking change)

But perhaps this is nevertheless a better approach? I'd really like to support disabling both --params-annotation and --non-null-annotation, and I'm hoping to add --nullable-annotation.

[bioball]

What is the reason to not generate @NonNull?

[odenix]

I’d like to support @Nullable, and I think many users will want one or the other.

[bioball]

Gotcha. The reason we went with @NonNull instead of @Nullable is because we only need to use one annotation, rather than two (@Nullable implies a @NonNullByDefault type of annotation too).

I'd be happy to accept a PR for this, though.

[stackoverflow]

Looks good!

[odenix]

After doing more research, I've come to the conclusion that disabling annotations with --params-annotation=none and paramsAnnotation = null is a better approach. I believe the same approach should be used for --non-null-annotation and a future --nullable-annotation. Please have another look. See commit message for details.