Add support for JEP 378 Text Blocks in order to optimize adding multiple statements in any specification.

[venkat1701]

So I was working on a personal project using javapoet to generate client sdk for a given openapi spec file. This is where I felt like its useful to have text blocks from JEP 378 to be implemented as a solution to avoid long chaining of addStatement() methods, which eventually makes the code hard to maintain and pretty large.

So for a demo example, using existing javapoet solution, we would write a hello world program something like this:

MethodSpec main = MethodSpec.methodBuilder("main")
    .addModifiers(Modifier.PUBLIC, Modifier.STATIC)
    .returns(void.class)
    .addParameter(String[].class, "args")
    .addStatement("$T.out.println($S)", System.class, "Hello, JavaPoet!")
    .build();

TypeSpec helloWorld = TypeSpec.classBuilder("HelloWorld")
    .addModifiers(Modifier.PUBLIC, Modifier.FINAL)
    .addMethod(main)
    .build();

JavaFile javaFile = JavaFile.builder("com.example.helloworld", helloWorld)
    .build();

javaFile.writeTo(System.out);

But with the proposed solution to this:

MethodSpec main = MethodSpec.methodBuilder("main")
    .addModifiers(Modifier.PUBLIC, Modifier.STATIC)
    .returns(voic.class)
    .addParameter(String[].class, "args")
    .addBlock("""
$T.out.println($S)
""", System.class, "Hello, JavaPoet!").build();
// rest of the things remain the same
...

Now there are multiple tradeoffs for this. Mentioning cons first:

1. Using text blocks may pose an issue with the backward compatibility of softwares that are currently relying on the same addStatement() method to generate dynamic code.
2. Making use of text blocks may also cause indentation issues for a user who maybe writes messy code with improper indentation.
3. These are all I can think of right now as its cons, which may increase with more discussion over this.

But the pros:

1. Repeated calls to addStatement() increases code length and also adds complexity.
2. Writing a construct, like a for loop, in multiple lines doesnt make much sense to add them to different lines. Instead of this, the solution can directly allow writing code blocks directly to a java file, integrated with string template literals, allowing the same functionality but better approach for long code constructs.
3. Allowing to accept higher order functions and lambda expressions to be passed as a method operation to be written in the java file. This will enable more modularity and better usage.

Although I might be wrong at many points here, but its just my perspective and I am open to discussions for why to go ahead with this or why to not.

Thanks,
Krish.