feat(go): support pseudo context aware commits

[codyoss]

Go regen PRs now enumerate all of the changes they contain. This
adds logic to parse those changes so individual entries appear in
the changelog. Example PR: googleapis/google-cloud-go#3391

[codecov]

Codecov Report

Merging #667 (2465324) into master (9ba60ee) will increase coverage by 0.01%.
The diff coverage is 92.00%.

@@            Coverage Diff             @@
##           master     #667      +/-   ##
==========================================
+ Coverage   83.01%   83.03%   +0.01%     
==========================================
  Files          45       45              
  Lines        5323     5352      +29     
  Branches      446      452       +6     
==========================================
+ Hits         4419     4444      +25     
- Misses        903      907       +4     
  Partials        1        1              

Impacted Files	Coverage Δ
src/releasers/go-yoshi.ts	93.30% <92.00%> (-0.99%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9ba60ee...2465324. Read the comment docs.

[bcoe]

@codyoss how much control do you have over the format of this upstream PR, I've been working on a grammar for conventional commits that would parse multiple commits in one PR:

https://github.com/conventional-commits/parser#the-grammar

I was picturing it would look like this:

feat(all): auto-regenerate gapics

This is an auto-generated regeneration of the gapic clients by
cloud.google.com/go/internal/gapicgen. Once the corresponding genproto PR is
submitted, genbot will update this PR with a newer dependency to the newer
version of genproto and assign reviewers to this PR.

If you have been assigned to review this PR, please:

Ensure that the version of genproto in go.mod has been updated.
Ensure that CI is passing. If it's failing, it requires your manual attention.
Approve and submit this PR if you believe it's ready to ship.

chore(recaptchaenterprise): migrate recaptchaenterprise to the Java microgenerator
Committer: @miraleung
PiperOrigin-RevId: 345559154
Source-Link: googleapis/googleapis@5e0dcb2
chore(securitycenter): migrate securitycenter to the Java microgenerator
Committer: @miraleung
PiperOrigin-RevId: 345559182
Source-Link: googleapis/googleapis@e5eef86

Or alternatively

feat(all): auto-regenerate gapics

This is an auto-generated regeneration of the gapic clients by
cloud.google.com/go/internal/gapicgen. Once the corresponding genproto PR is
submitted, genbot will update this PR with a newer dependency to the newer
version of genproto and assign reviewers to this PR.

If you have been assigned to review this PR, please:

Ensure that the version of genproto in go.mod has been updated.
Ensure that CI is passing. If it's failing, it requires your manual attention.
Approve and submit this PR if you believe it's ready to ship.

chore(recaptchaenterprise): migrate recaptchaenterprise to the Java microgenerator
  Committer: @miraleung
  PiperOrigin-RevId: 345559154
  Source-Link: googleapis/googleapis@5e0dcb2
chore(securitycenter): migrate securitycenter to the Java microgenerator
  Committer: @miraleung
  PiperOrigin-RevId: 345559182
  Source-Link: googleapis/googleapis@e5eef86

The difference being, no * in front of each commit, and no \n\n between each commit.

My reasoning is that this allows us to extend on the already supported footers in Conventional Commits, giving us the functionality of multiple commits, without adding significant complexity to the specification.

CC: @miraleung

[codyoss]

I have some control. All I do is create the "Changes" section and add bullets to each new commit. I do no formatting the the commits themselves. Between the two suggestions you provided I would lean towards the second as the first is hard to grok as a human. Although I think what is currently there is still reads better for humans.

If there is not a standard way to do this today I would prefer to just keep this for now, and iterate later when something solid is locked down.

[bcoe]

Closing in favor of #686