Add phi -> unphi -> test pipeline

[deemp]

• Add a GH Actions workflow that runs eoc phi -> eoc unphi -> eoc test on selected EO tests
• Make transform-eo-tests a CLI app so that it can be reused in objectionary/normalizer
• Sample run in my fork - https://github.com/deemp/eo/actions/runs/8194327513
• Skip some tests (see pipeline/config.yaml)

---

PR-Codex overview

This PR updates the pipeline configuration, adds dependencies, and sets up workflows for a Haskell project.

Detailed summary

• Added transform-eo-tests dependency in pipeline/stack.yaml
• Updated pipeline/package.json with eolang dev dependency
• Added ignore rules in .gitignore and pipeline/.gitignore
• Updated pipeline/stack.yaml resolver to lts-22.6
• Added phi-unphi-test.yml workflow for pipeline execution
• Updated pipeline/run.sh script for preparing directories and running tests
• Added config.yaml with test configurations

The following files were skipped due to too many changes: pipeline/config.yaml, pipeline/transform-eo-tests/app/Main.hs, pipeline/package-lock.json

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

[deemp]

@maxonfjvipon, @yegor256, please review

[maxonfjvipon]

@deemp could you please make one more commit to restart CI?

[maxonfjvipon]

@yegor256 @volodya-lombrozo WDYT? Will we be able to maintain it? Because I'm not really sure. If it were javascript, maybe it would be OK, but I doubt about haskel

[deemp]

@maxonfjvipon, the Haskell code selects tests specified in pipeline/config.yaml and writes them to destinations specified in that file. I think it's actually a task for eoc.

I don't insist that eoc use the current format of config.yaml. However, I do want eoc to support features currently supported via this format.

I believe this PR can be used just for integration testing of the phi -> unphi -> test pipeline until eoc can run tests selectively.

[volodya-lombrozo]

@maxonfjvipon, I don't think that Haskell is a big problem here. As @deemp said, we can always implement this logic in eoc. For now, we can just leave a puzzle to implement this functionality later. I have some doubts about the code in this PR and the pipeline implementation details (it seems we can simplify it).

However, it's worth mentioning that this integration test is helpful, and it's better to have it at least in this form. Then, we can refactor it.

[deemp]

@maxonfjvipon, @volodya-lombrozo

it seems we can simplify it

It's still an open question how to simplify the pipeline - see objectionary/eoc#247

[maxonfjvipon]

@deemp thanks for the contribution and the idea provided, but we've made up with more convenient solution #3146