feat(flatzinc-serde): Support for the original FZN format

[maartenflippo]

The flatzinc-serde crate has a great AST that is based on the JSON format for FlatZinc. Having a single crate that can parse both the FZN JSON and original FZN formats would be great. Hence, this PR introduces a parser for FZN based on the winnow parser combinator library.

The implementation comes with both unit and integration tests for the parser. The integration tests are taken from the libminizinc spec tests. Since flatzinc-serde does not have explicit integration tests, these are also included in the fzn/mod.rs file. There is a single test function that reads the fixtures from crates/flatzinc-serde/corpus/fzn and parses them all. Similar to the JSON parser tests, expect_file is used to handle snapshots.

TODO

• Parse predicate statements
• Parse parameter items
  • In the JSON format, parameters do not exist, so the FlatZinc type does not have a field for parameters. In my opinion, this means we should resolve parameters in the FZN parser. That way, the parameters are not visible to a user of this functionality. The other option would be to add a parameters field to FlatZinc, but I would expect that is not a desired solution.
• Parse variable items
• Parse variable array items
• Parse constraint items
• Parse solve items
• Pass the integration tests (see crates/flatzinc-serde/corpus/fzn/).

Questions

1. How should parameters be handled? See the TODO list for some thoughts on this.
2. Should the integration tests be moved to a tests/ directory? This would support easy filtering of the tests using cargo test --lib and cargo test --tests (which runs the tests in the tests/ directory).
3. Should we build in support for string interning? At least in our solver, we try to use interned strings for identifiers, which, on large FlatZinc files, can be very useful. But the impact is somewhat limited and of course dwarfed by solving time in general.