Switch to KotlinPoet Code Generation

[stabbylambda]

What Changed

Over the last week, @phubbard and I spent some time converting things to Kotlin Poet. The result is infinitely better than the previous string concatenation code. We were able to reduce some of the duplication between the Sync and Async versions of various hooks, the code isn't as brittle, and it's all using real type references from KSP instead of just hoping the Strings work out.

Todo:

• SyncHook
• The rest of the hooks
• Delete all the godawful string manipulation code

📦 Published PR as canary version: 0.12.1-canary.28.294-SNAPSHOT

[sugarmanz]

When I was migrating from meta -> KSP in the first place, I tried to pull out all the intermediate data into pure codegen constructs, rather than a dependence on the modeling framework. This would ensure the codegen code is truly agnostic and you could potentially use the codegen module without needing the KSP part. i.e. if we want to use another processing framework (live javax.processing), or change the actual way we represent the DSL, or generate hooks via CLI.

I would like to try to continue following the strict separation of concerns. They can certainly be updated from simple String representations to whatever poet representation works best (TypeName, etc.).

Thoughts?

[stabbylambda]

We discussed this earlier, but just putting this here for posterity. Today, we have multiple areas where we reach into the type resolver to get the information necessary to codegen the new class. When @sugarmanz looked at this, some of that was happening in the codegen, some in the validator, some in the processor. Instead what we discussed was making the whole pipeline a bit cleaner by changing it to be:

1. process KSP -> Poet
2. validate Poet constructs
3. code generate from Poet constructs

That way any potential frontend (we're not switching away from KSP anytime soon) just has to convert to KotlinPoet classes.

[sugarmanz]

🚀 PR was released in v0.12.1 🚀