Consider unteaching `ServiceCodeGenerator` about sources vs. headers

We could have one `ServiceCodeGenerator` per file, instead of one `ServiceCodeGenerator` per potential pairs of files.

`ServiceCodeGenerator` writes files. It takes care to distinguish between headers and sources. It has a separate `Printer` for source and header. It has many `CcFoo()` / `HeaderFoo()` member functions. But the implementation of these member functions are basically the same.

**Why we would do this:**
- I am about to introduce a hacky overload because I want a `ServiceCodeGenerator` that only writes a source file.
- Simplify the class. I suspect it will be easier to navigate. (I often forget whether I am in `GenerateHeader()` or `GenerateCc()`)
- We could parallelize writing headers and sources. The savings, if any, would be negligible.

**Why we wouldn't do this:**
If there was a ton of common code shared between headers and sources, then having one class to control both makes sense.

- The client generators have a shared initialization for `{get,set}_iam_policy_extension_`.
- The connection generators share a `ConnectionFactoryFunctionArguments()`

We could always factor this stuff out. The processing could happen in `make_generators.cc`, instead of inside the generator. e.g. Each `ServiceCodeGenerator` calls `SetMethods()` which does the same work to produce its `methods_`, `async_methods_`. That could also happen once outside of the `ServiceCodeGenerators`.

Beginne mit dem Lesen von ServiceCodeGenerator und make_generators.cc und konzentriere dich dabei auf die gemeinsame Initialisierung, SetMethods(), methods_ und async_methods_. Ermittle, wie die aktuellen Funktionen CcFoo()/HeaderFoo() und die separaten Printers die Ausgabe von Quelltext und Header koordinieren. Als abgeschlossen gilt die Aufgabe, wenn die Generatorstruktur die vorgeschlagene Trennung pro Datei widerspiegelt, ohne das Verhalten des gemeinsamen Client- und Connection-Generators zu verlieren.

Vom Indexierungsmodell aus dem Issue-Text verfasst.