add mergeText plugin

[johnkenny54]

Consolidate adjacent <text> elements and <text> elements with a single <tspan> child.

Resolves #964, resolves #1907

[johnkenny54]

There are problems with the commits in my branch. Closing this PR, will reopen with a clean copy.

[SethFalco]

Thanks for opening and maintaining the pull request!

When you do have it open, I'll review it once SVGO v3.2.0 is released. Meanwhile, it will probably help if you update with a rebase instead of merge next time!

Assuming origin is your fork and upstream is this repository.

git fetch --all
git rebase upstream/main

Then if there are any conflicts, you can resolve them and do:

git add .
git rebase --continue

This results in a clean commit history, no merges required. 👍🏽
If you ever have trouble because of too many conflicts, it's simpler to squash your commits first and then rebase with upstream after.

git rebase -i HEAD~N # replace N with the number of commits you want to squash
# an interactive editor appears, replace "pick" in all lines except the first with "s"

# now rebase with upstream as normal
git fetch --all
git rebase upstream/main

If you ever have trouble with it again, welcome to ask me to fix it for you, and I'll record how I do it.

[KTibow]

Thing is that usually merges work fine and don't include upstream commits in the change view, but I think somewhere commit history got changed, resulting in discontinuity across past upstream and current upstream. I ran into this when rebasing another PR I made, and fixed it by git reset --hard HEAD~1ing (deleting the previous merge commit) before retrying the merge and force pushing.

[SethFalco]

Interesting, I always use rebase, so I haven't run into that issue.

commit history got changed

In the past, some maintainers have done force pushes to main, however, that forcefully closes all pull requests that target it. That shouldn't be the problem now.

I'm guessing it's because we use the "Squash and merge" strategy to merge pull requests.

Because this commit is only on the base branch and not the head branch, the common ancestor of the two branches remains unchanged. If you continue to work on the head branch, then create a new pull request between the two branches, the pull request will include all of the commits since the common ancestor, including commits that you squashed and merged in the previous pull request.

— https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#squash-and-merge-your-commits

I, personally, like "Squash and merge" and "Rebase and merge". I'd recommend contributors/maintainers to rebase to keep local branches up-to-date instead of merging.

Looking online, it seems to come down to preference. One way isn't objectively better. I, personally, prefer rebase since I feel merges clutter the commit history. Though, I may consider what's happening now a point for why rebasing is easier.