Port ComClassGenerator to string writing instead of constructing syntax nodes

[DoctorKrolic]

The easiest part of #95882

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

[jkoritzinsky]

Looks pretty good! If you're taking a stab at this work, there's one more piece I'd like to figure out. Can we introduce a new type that doesn't store syntax nodes to handle the containing syntax (such as a type that, given syntax, computes a prefix, indent value to use for contents, and suffix)?

That way we could get to a point where we aren't passing syntax around between steps, as that's one of the main reasons we want to move to strings.

[DoctorKrolic]

Can we introduce a new type that doesn't store syntax nodes to handle the containing syntax

I would like to revisit pipeline models after we port all generators to strings. This way I can focus on the "back side" of the pipeline without diving into the data collection part of it. Yes, this generator is the simplest of them, but for others trying to tweak the front and the back side at the same time might be challenging. For the transition period syntax is still a good common denominator since it is both siutable for node construction and string writing due to convinience of To[Full]String(). Porting to strings without changing the models still has value in simplification and reduction of all intermediate node allocations