Support custom rewrite rule sets as input

[fizruk]

Based on #9. Closes #11.

• Generic (naïve) mechanism for normalization (Language.EO.Phi.Rules.Common)
• User-defined rules (with YAML configuration) (Language.EO.Phi.Rules.Yaml)
• Basic CLI:
  • --rules-yaml FILE
  • --chain (not implemented yet)
• Sample rules file (based off Yegor's rules) (yegor.yaml)
• A few unit tests

Known issues/limitations:

• Not all conditions/patterns are supported:
  • presence/absence of an attribute
  • (in)equality of attributes
  • reference to global object bindings
  • global counter
  • attribute (re)naming utilities
• isNF condition does not adequately represent intended restrictions (need to consider context somehow)
• Cannot support minimal calculus (locator substitution is not implemented/available)
• Missing documentation
• Not enough tests

---

PR-Codex overview

Focus of this PR:

This PR focuses on introducing new features and improvements to the EO Phi normalizer.

Detailed summary:

• Added support for MetaObject and MetaBindings in the Object data type.
• Updated the Syntax.cf grammar file to include the MetaId token.
• Updated the Syntax.Par.y parser file to handle the MetaId token.
• Modified the Setup.hs file to use the --haskell flag when invoking bnfc.
• Updated the VS Code settings file to set the default formatter for Haskell files.
• Added new test cases and test files for user-defined rules.
• Updated the Language.EO.Phi module to import qualified modules.
• Made various improvements and bug fixes to the codebase.

The following files were skipped due to too many changes: eo-phi-normalizer/src/Language/EO/Phi/Syntax/Par.y, eo-phi-normalizer/eo-phi-normalizer.cabal, eo-phi-normalizer/src/Language/EO/Phi/Syntax/Doc.txt, eo-phi-normalizer/src/Language/EO/Phi/Rules/Common.hs, eo-phi-normalizer/src/Language/EO/Phi/Syntax/Print.hs, eo-phi-normalizer/app/Main.hs, eo-phi-normalizer/src/Language/EO/Phi/Rules/Yaml.hs

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

[deemp]

I think we shouldn't be non-deterministic here as it can badly affect the performance (IDK if laziness saves us).

So, maybe apply listToMaybe instead of returning a list?

[fizruk]

Sensible suggestion if we expect at most one match. However, this is not currently the case if Rule.Binding contains a metavariable binding (i.e. we should match any metavariable). To make this efficient we should then somehow stop and let other part of the matching figure out what metavariable we are talking about, which can be done in some places by rearranging order of matching (for example, for ObjectDispatch). However, this is not possible in general without constraint-based matching.