Refactor PR body parsing

[oleg-codaio]

As part of adding support for including the stack in PR bodies (see #264), we'll need to extend templating support to handle more than one section:

<!-- av pr stack begin --> { stack here } <!-- av pr stack end -->

Here is the main PR body description.

<!-- av pr metadata
This information is embedded by the av CLI when creating PRs to track the status of stacks when using Aviator. Please do not delete or edit this section of the PR.
` ` `
{"parent":"some-parent","parentHead":"abcdef","parentPull":123,"trunk":"main"}
` ` `
-->

The current ParsePRMetadata() implementation is efficient, but makes it hard to support another section.

This PR updates ParsePRMetadata and AddPRMetadata to instead make use of substrings and strings.Builder. Performance isn't really a concern here - these PR bodies aren't that big and we spend a lot more time interacting with the git CLI anyway.

[aviator-app]

Current Aviator status

Aviator will automatically update this comment as the status of the PR changes.
Comment /aviator refresh to force Aviator to re-examine your PR (or learn about other /aviator commands).

This PR was merged using Aviator.

---

See the real-time status of this PR on the Aviator webapp.

Use the Aviator Chrome Extension to see the status of your PR within GitHub.

[aviator-app]

FlexReview Summary

Based on the code complexity and the author's expertise score, these are the suggested reviewers:

• @draftcode (current review load: 4)

See the list of alternate reviewers in the detailed breakdown below.

Detailed Breakdown

Author’s expertise score for the modified files:

• internal/actions/pr.go (0.00)
• internal/actions/pr_test.go (0.00)

Files	Reviewers
internal/actions/pr_test.go †	@draftcode (score: 1.00, current review load: 4)

† Indicates that the file doesn't need an expert review. (?)

See full breakdown of the reviewers on the Aviator webapp.

[oleg-codaio]

I removed the newline here because I noticed when I'd edit the PR manually on GitHub, I'd end up with a carriage return, i.e., "<!-- av pr metadata\r\n" and this parsing would break. Instead, opting to just parse this directly and add any extra whitespace padding explicitly.