fix: parse headerPatternCorrespondence properly

[G-Rath]

The conventional commits parser expects to be passed an array for headerCorrespondence but currently we're passing a plain string.

Ideally this should be done using newlines like other arrayish inputs, but since that would be a breaking change for now I've just introduced an ugly inline parse and a todo for the next major.

See my testing here: G-Rath#2

Resolves #294

[G-Rath]

I've not been able to prove this should be working on v5 (G-Rath#3) but I'm happy to chalk that up to having just not put enough effort in 🤷

Ironically this seems like an undocumented breaking change in the parser - pre-v6 a string is supported:

Used to define what capturing group of headerPattern captures what header part. The order of the array should correspond to the order of headerPattern's capturing group. If the part is not captured it is null. If it's a string it will be converted to an array separated by a comma.

but the changelog for v6 does not call out this no longer being supported

[amannn]

Thanks a bunch @G-Rath for jumping in here, really appreciate it! ❤️

And yes, I think this fixes exactly what went wrong here. I agree with your reasoning regarding converting this to an array for the next major.

Ironically this seems like an undocumented breaking change in the parser

It seems like, yes! Unfortuantely the test suite also didn't catch it, but the workflow you added should help to avoid regressions related to this in the future.

[github-actions]

🎉 This PR is included in version 6.1.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[amannn]

@G-Rath I haven't had any reports anymore about problems on v6 after this PR, just wanted to thank you again for your help fixing the regression I've introduced. I really appreciate it! ❤️