Generate docs of enums and rpc clients, some refactoring

[osa1]

This implements generating doc comments for enum types, enum values, rpc types,
and rpc methods.

Existing code for generating doc comments is refactored: the comment generator
handles trailing whitespace so we don't have to handle it in the call sites.
Comment generator is documented with the invariants: it never returns an empty
string (returns null instead) and never returns lines with trailing
whitespace.

To be able to test comment generating, a new kind of golden file test is added.
The difference from the other golden file tests is that this file is compiled
from .proto source instead of from a hand-crafted descriptor. This is because
attaching comments to proto field and types by hand is difficult and error
prone.

Fixes the comment part of #900.

---

cl/596840489

[github-actions]

Package publishing

Package	Version	Status	Publish tag (post-merge)
package:protobuf	4.0.0-dev	ready to publish	protobuf-v4.0.0-dev
package:protoc_plugin	22.0.0-dev	ready to publish	protoc_plugin-v22.0.0-dev

Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation.

[osa1]

@sigurdm for field comments, any thoughts on which accessors should have the comments copied?

Currently for a field x we generate these public members:

• get x
• set x
• hasX
• clearX

The documentation is currently copied only to get x, but deprecation annotations are added to all of these (in master branch, not with #908).

If duplicating potentially large comment blocks 4 times is not a problem I think we should add docs to all.

[sigurdm]

@sigurdm for field comments, any thoughts on which accessors should have the comments copied?

Really good question. I don't think the setter should have it: https://dart.dev/effective-dart/documentation#dont-write-documentation-for-both-the-getter-and-setter-of-a-property

Perhaps the hasX should just have a referring comment along the lines of:

Checks for presence of [X].

True if [X] has been set.

And clearX:

Unsets [X].

[osa1]

Makes sense, and thanks for the reference.

In that case I think we don't have to change anything in this PR.

I'm not sure if "clearX" and "hasX" docs are necessary, but if we want them we can add them separately.