Allow processor to opt in to new features in KSVisitors

[jaschdoc]

The idea in this PR is that a processor must opt-in to the new features such as backing fields. This is all done without breaking binary compatibility, so processor authors can upgrade to new features and users can still build their projects.
Specifically, this PR addresses the situation where a processor uses one of the built-in KSVisitor implementations provided by KSP. An existing processor will not see any change and will continue to work. An existing processor may opt-in to the new features.

This is similar and related to #3110. Note that the flag introduced in this PR is decoupled from the one in #3110.

Related to #2969
Related to #2472
Related to #2873

[troelsbjerre]

Why not just pass this as a default parameter?

[jaschdoc]

That's not binary compatible. Consider the following example:

class A(val a: Int, b: Int = 0) // default parameter
class B(val a: Int, b: Int) {
    constructor(a: Int) : this(a, 42) // Secondary constructor
}

Then the disassembled output has the following constructors:

  public A(int, int);
    descriptor: (II)V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=2, locals=3, args_size=3
         0: aload_0
         1: invokespecial #9                  // Method java/lang/Object."<init>":()V
         4: aload_0
         5: iload_1
         6: putfield      #13                 // Field a:I
         9: aload_0
        10: iload_2
        11: putfield      #16                 // Field b:I
        14: return

  public A(int, int, int, kotlin.jvm.internal.DefaultConstructorMarker);
    descriptor: (IIILkotlin/jvm/internal/DefaultConstructorMarker;)V
    flags: (0x1001) ACC_PUBLIC, ACC_SYNTHETIC
    Code:
      stack=3, locals=5, args_size=5
         0: iload_3
         1: iconst_2
         2: iand
         3: ifeq          8
         6: iconst_0
         7: istore_2
         8: aload_0
         9: iload_1
        10: iload_2
        11: invokespecial #21                 // Method "<init>":(II)V
        14: return

and

  public B(int, int);
    descriptor: (II)V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=2, locals=3, args_size=3
         0: aload_0
         1: invokespecial #9                  // Method java/lang/Object."<init>":()V
         4: aload_0
         5: iload_1
         6: putfield      #13                 // Field a:I
         9: aload_0
        10: iload_2
        11: putfield      #16                 // Field b:I
        14: return

  public B(int);
    descriptor: (I)V
    flags: (0x0001) ACC_PUBLIC
    Code:
      stack=3, locals=2, args_size=2
         0: aload_0
         1: iload_1
         2: bipush        42
         4: invokespecial #24                 // Method "<init>":(II)V
         7: return

Class A's secondary constructor actually has four parameters instead of one whereas class B's secondary constructor has the one parameter as expected.