Add symbol processor for configuration metadata

[salatmaster]

This adds spring-boot-configuration-symbol-processor, a KSP processor that generates configuration metadata for Kotlin sources, as an alternative to running the annotation processor through kapt. It reuses the metadata model of the existing annotation processor, so the generated META-INF/spring-configuration-metadata.json is identical in format.

Besides removing the need for kapt, it fixes metadata that kapt currently loses. For a data class with Kotlin defaults:

@ConfigurationProperties("demo")
data class DemoProperties(val port: Int = 8080, val name: String = "demo")

kapt generates a stub with two constructors, the annotation processor can no longer deduce the bind constructor, and no properties end up in the metadata at all — only the group. The symbol processor describes both properties. KDoc on constructor parameters (@property) is picked up as well, which kapt drops.

Supported: constructor and JavaBean binding, @DefaultValue, @Name, nested groups, @NestedConfigurationProperty, @ConfigurationProperties on a method, actuator endpoints, deprecations, KDoc descriptions, merging of additional-spring-configuration-metadata.json, and @ConfigurationPropertiesSource.

Known limitations, all covered in the new appendix section:

• Default values declared with an initializer are invisible to KSP ([feature request] Retrieve property default value for compile time constants google/ksp#1868). kapt does not expose them either, so this is not a regression, and @DefaultValue still works.
• Additional metadata has to be located with a processor option, since KSP gives a processor no access to module resources.
• A module has to apply either this processor or the annotation processor, as both write the same file.
• Endpoint annotations are matched directly rather than through meta-annotations.

Tests drive the processor through the KSP2 API directly, so there is no third-party test dependency. The processor is compiled against symbol-processing-api 2.3.0 and declares it as compileOnly, so the KSP version stays under the user's control.

I'm aware this is marked as pending design work, so please treat it as a concrete proposal rather than a finished feature — happy to rework it if you'd rather see a different shape, such as an abstraction shared with the annotation processor.

See gh-28046