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.

Commencez par lire ServiceCodeGenerator et make_generators.cc, en vous concentrant sur l'initialisation partagée, SetMethods(), methods_ et async_methods_. Déterminez comment les fonctions actuelles CcFoo()/HeaderFoo() et les Printers séparés coordonnent la sortie du code source et des headers. Le travail est terminé lorsque la structure du générateur reflète la séparation proposée par fichier sans perdre le comportement partagé des générateurs de client et de connexion.