ci: change how upstream project is tracked

[krzema12]

Before this change, we simply stored a hash of the latest commit in snakeyaml-engine that we ported over to snakeyaml-engine-kmp. The idea was to port the changes one after another, assuming it would be easy. However, given our latest problems to port one of the commits (#272) so that it works on all targets, it's not good to block on this single change with porting other changes.

One idea would be to note with better granularity which commits have been ported. However, it would cost us quite a bit to add this mechanism, instead of focusing on actually porting the changes.

That's why I propose changing the semantics of the counter displayed in the README: show how many changes weren't analyzed by us. In other words, as soon as we acknowledge a given upstream change by creating a proper issue in our project, we can assume this change is "analyzed". Then, in our own pace, we can take care of porting the changes, possibly doing it in parallel. Thanks to this approach, changes that are harder to port will naturally be ported later, and won't block porting easy changes, which is good for the users of the lib.

I've created these issues under a new label to track the changes to port: https://github.com/krzema12/snakeyaml-engine-kmp/issues?q=is%3Aissue+is%3Aopen+label%3A%22port+from+snakeyaml-engine%22

You can cross-reference it with https://raw.githubusercontent.com/krzema12/snakeyaml-engine-kmp/refs/heads/commits-to-upstream-badge/log-diff-between-repos.txt

[OptimumCode]

All looks good to me. But I would add an explanation about the counter to the README file (just to have it right by the counter itself)

[krzema12]

Ok, I'll add it in a separate PR!

[krzema12]

@OptimumCode #296