feat: add KPAR compression options

[Jonas-Puksta-Sensmetry]

Addresses #174.
Add bzip2, zstd, xz, and ppmd KPAR compression methods gated behind feature flags kpar-bzip2, kpar-zstd, kpar-xz, and kpar-ppmd respectively.

[consideRatio]

@Jonas-Puksta-Sensmetry I haven't really looked at this PR besides the CI failure, but with @andrius-puksta-sensmetry approving review and the commit I pushed to fix a real failure, I think you should merge if you found 1ce5ab8 to be OK!

[consideRatio]

@victor-linroth-sensmetry does 1ce5ab8 look okay to you? Should we go for a merge? Eager to reduce the amount of open PRs ;D

[victor-linroth-sensmetry]

I'll see if I have time to look at it later.

[consideRatio]

I lack the background to this PR and wasn't part of the discussion leading up to it, sorry for the late input! I'm not looking for a discussion to onboard me, but for a quick self-check that you still think it's good to do this.

1. Flexibility for one user packaging something imposes more requirements on the user unpackaging it. Is supporting more flexibility actually positive?
2. The .zip archives uploaded to PyPI, etc., for wheels and source code are constrained for security reasons, I recall. I recall security fixes to protect PyPI users from unsafe uploads, where during extraction there could be mischief like unzipping to relative paths outside the folder you meant to extract to, potentially overriding .bashrc or something like that. Are we feeling confident that this isn't causing issues like that?

[andrius-puksta-sensmetry]

Flexibility for one user packaging something imposes more requirements on the user unpackaging it. Is supporting more flexibility actually positive?

This is why we by default will support only no compression and deflate (which is used ~everywhere by default). Other compression methods are exposed to enable benchmarking and possibly choosing a different default in the future, depending on how well they compress SysML2 JSON representation, as that representation tends to be huge.

The .zip archives uploaded to PyPI, etc., for wheels and source code are constrained for security reasons, I recall. I recall security fixes to protect PyPI users from unsafe uploads, where during extraction there could be mischief like unzipping to relative paths outside the folder you meant to extract to, potentially overriding .bashrc or something like that. Are we feeling confident that this isn't causing issues like that?

I don't see how this would affect security. It only changes the compression algorithm, metadata AFAIK remains exposed in exactly the same way.

For more details/rationale ask Vytautas.