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`.

まず ServiceCodeGenerator と make_generators.cc を読み、共有初期化、SetMethods()、methods_、async_methods_ に注目します。現在の CcFoo()/HeaderFoo() 関数と分離された Printers が、ソースとヘッダーの出力をどのように連携させているかを確認します。クライアントと接続の共有ジェネレーターの動作を失うことなく、ジェネレーター構造が提案されたファイル単位の分離を反映していれば完了です。

索引モデルが issue の本文から書いたものです。