This might be a big diff, but I _hope_ that it does not change much
functionally (hopefully it changes nothing generation specific).
What has changed?
-----------------
- I had to merge the three crates into one, to allow `macros` to impl
functions on Types defined in `parser`.
- As mentioned in the point above, the conversion function are now
inherent to the type they convert (i. e. `r#type.to_rust()` instead of
`type_to_rust(r#type)`).
- The conversion function have been sorted, by what they convert to:
- `to_rust()` converts a type to be used in rust *host* code.
- `to_c()` converts a type to be used in c *host* code.
- `to_auxiliary_c()` converts a type to be used in c *auxiliary*
code.
- The top-most `generate` method of `TrixyConfig` now returns a
`FileTree` instead of writing the files directly. The `FileTree` can
still be materialize with the `materialize` method. But this change
facilitates moving non-generation focused code out of the `generate`
method.
What is the difference between _host_ and _auxiliary_ code?
-----------------------------------------------------------
Auxiliary code is always written in the language it is generated for. So
auxiliary code for c would be written in c (or at least in a subset of c),
as it represents c header files.
Host code is always written in rust. This is the code that is
responsible for implementing the actual ffi stuff. In our case these are
the `extern "C"` functions and the types, defined in trixy.
The rust host code is generating the native rust representations of
these types.
Errors were contextualized by finding their index in the source file.
This method is extremely flaky, as it _hopes_ that the line is not
spread over multiple lines.
The new method actually uses the span to calculate a matched line and
thus avoids any issues related to the actual position of the line in the
source file.