Support property evolution: deprecated, hidden, computed defaults

[vlsi]

Build parameters are a part of build system API, and it would be nice to provide migration path for the properties.

Consider a scenario:

1. I've added jdkBuildVendor, jdkBuildVersion, jdkBuildImplementation parameters quite some time ago when build-parameters did not support groups:
   https://github.com/pgjdbc/pgjdbc/blob/6daee7d4251d568d3de52afd3bbfa8328f296681/build-logic/build-parameters/build.gradle.kts#L30-L44
2. Now I consider migrating to groups like jdk.build.version, jdk.build.implementation and so on. The issue is that there might be end-users who have their own shell scripts and CI systems that still use old property names. If I rename the build properties, it would make their build invalid

I would like to have property evolution (e.g. consider Kotlin's @Deprecated), so I could:

1. Mark properties as deprecated, so the users get warnings if they still use them
2. Mark properties as hidden, so they work, yet they are hidden from the documentation
3. Allow "new" properties to fetch the values from the older ones. For instance, if I add jdk.build.version, I would like to still support users that still use -PjdkBuildVersion=17 (~make the default of jdk.build.version compute based on jdkBuildVersion property)

[britter]

We think deprecation cycles is something that fits into the build parameters plugin. We're not sure about hidden states, maybe it's just the default for deprecated parameters instead of having a dedicated flag. We're thinking more in terms of replaced instead of deprecated. Last but not least, computed values have come up multiple times, but it's difficult / impossible to implement them in a general way, because in the parameters DSL, you don't have access to the actual property value and type, so you can't implement calculations.

In general we feel like we've reached the limits of the generation approach and would rather like to look into a way of making build parameters a settings script concept. But that requires a lot of work and nobody on the team really has time to put more effort into this plugin at the moment.