This change makes it possible to see the people who were requested
as reviewers, which helps understand the context for notifications
about CLs better.

Sort inline comments by file name and line number, so that their order
is deterministic. Previously, it was non-deterministic due to reliance
on map iteration order.

There's still a small chance for non-determinism in comment order when
there are multiple inline comments in the same file on the same line.
Leave dealing with that case for later when running into it concretely,
because it's not clear if it's something that can actually happen.
If it becomes necessary to resolve it, it should be possible to use
inline comment IDs to break the tie.

It's helpful to visualize hashtags applied to CLs.
Do so by mapping them to labels.

The commit message should always have a subject and headers,
but the body (providing additional information) may be absent.
Detect that case and return empty string, rather than erroneously
returning the headers as the body.

Also add some basic tests.

Comments are meant for entries that contain non-empty content. Some
entries contain, e.g., a Run-TryBot+1 vote, but otherwise empty body.
We may want to visualize such timeline entries in a more lightweight,
event-like manner. For now, just skip them instead of displaying
empty comments.

When a Gerrit CL change is restored, there should be an
associated ReopenedEvent. This change implements that.

I've finally encountered a Gerrit CL that was restored,
so this change could be tested on it:

	https://go-review.googlesource.com/c/build/+/169198

This specifies the notification thread type for Gerrit changes. It will
be used by the changes application for marking Gerrit changes read.

This is more consistent with other change service implementations,
and provides more useful context when viewing the change discussion.

Use the CurrentRevision of the CL to determine the merge commit,
rather than unsafely parsing it out of the human-readable message.

Background

Up until recently, all "autogenerated:gerrit:merged"-tagged messages
that I've encountered on the Gerrit instance at https://go-review.googlesource.com
have started with the 46-byte-long "Change has been successfully
cherry-picked as " string, followed by a 40-byte-long commit hash.

I didn't originally see a way to retrieve the merged commit from the
API response directly, so I implemented an unsafe string slice
operation that assumed the familiar message format.

A CL that used merge submit type rather than cherry-pick was submitted
at https://go-review.googlesource.com/c/go/+/164238/1#message-e75ad5d4bec9069a005bdc9efad6fbe8af8eb935
and generated a "autogenerated:gerrit:merged"-tagged message with
a different format, causing a panic.

By now, I've found a way to use the Gerrit API to determine the merge
commit. When a CL has an "autogenerated:gerrit:merged"-tagged messaged,
the CurrentRevision of the CL is the merge commit. Use it, since it's
more robust and safe.

This is yet another possible newPatchSet message format.

See example at https://go-review.googlesource.com/c/tools/+/151057/5#message-def598911f85f6435674a5ebeccc9981cfc59195.

Display a closed event when a CL is abandoned, and the abandon reason
if one is provided.

It's possible for messages with the "autogenerated:gerrit:newPatchSet"
tag to also set labels, which wasn't previously supported. E.g.:

	Uploaded patch set 4: Run-TryBot+1.

	(1 comment)

Or:

	Uploaded patch set 5: Run-TryBot+1.

Update the code to handle these.

Some messages with the "autogenerated:gerrit:newPatchSet" tag have a
different format than previously expected:

	Patch Set 3: Commit message was updated.

I'm not aware that such messages could have inline comments, so handle
them by looking for a "Patch Set " prefix, and stop there. No need to do
more for now.

In Gerrit, it's possible to publish inline comments on patchset push.
Such messages look like this:

	Uploaded patch set 2.

	(3 comments)

Parse and display such comments.

Use the more explicit project~id change ID format. It's not deprecated,
and lets us detect and return a not exist error when the project doesn't
match the CL.

Previously, just the numeric change ID was used. That format is
deprecated, and doesn't tell us when the project doesn't match the CL.

References:

• https://gerrit-review.googlesource.com/Documentation/rest-api-changes.html#change-id
• https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#change.api.allowedIdentifier

Previously, the review state wasn't correctly parsed when there
was more than 1 label (e.g., "Run-TryBot+1 Code-Review+2").

Example of an affected review is https://go-review.googlesource.com/c/go/+/112935#message-45e0d04e5f087880438b34c77b6b683f0beffaa3.

Remove commented out code. It can be added when/if needed.

We need to fetch messages in Get method, so that counting them works.
Previously, len(chg.Messages) was always zero, and so was Replies as
a result.

Make project helper implementation simpler by making its error handling
path indented, and the normal execution path not indented.

Make it more consistent across the services.

This is to avoid naming conflicts for upcoming package rename from
changes to change.

These are not actual comments, they add noise. Perhaps we can display
them as events in the future.