Consider testing elements metadata tests via Kapt

[ZacSweers]

Currently we do these via in-memory compiler + elements, but this actually behaves differently from kapt stub generation in some ways and has led to surprising issues like #1046. It would be cool if we could exercise kapt directly as a part of these tests, likely via kotlin-compile-testing and similar to how we do ksp interop tests.

Main issue is some specs don't actually compile, but maybe we can just allow that and ignore the exit code and just verify generated file contents.

[ZacSweers]

At a high level, I'm thinking of this:

• Restructure the specs test to test with FileSpecs rather than just types, since we'd be writing these spec files to a file.
• Abstract the creation of a spec from individual tests. They would just supply a target class and expected source
• Abstracted function would run a test processor via KCT (if testing elements) or reflection

[ZacSweers]

One open question is - do we want to still test the in-memory elements form too? That would behave like a traditional java annotation processor, but unsure if that's truly a case that would happen in the wild.