This allows using external functions in datalog.

This makes it easy to provide custom logic without extending the spec for every use-case, at the expense of portability: behaviour is no longer guaranteed to be consistent cross languages, and some languages won’t be able to support it at all (for instance JS as of now).

Todo:
- stricter conversions from datalog
- feature-gating if possible

Open questions:
- enum index for the FFI variants (contiguous or not?)
- how to provide functions (right now, function pointers: prevent mutability and closing over arguments)
- how to provide arguments (right now, datalog::Term, so symbols have to be resolved, and functions returning strings have to register new symbols)

- using boxed functions instead of function pointers allow capturing the environment
- using builder terms instead of datalog terms remove the need for manual symbol management

Instead of storing strings directly in the ops, do as we do for everything else and use the symbol table.

This required duplicating `biscuit_parser::builder::Binary` and `Unary` in the `biscuit_auth::builder` module (which previously used the definitions from the `datalog` module directly). There is a lot of duplication between `biscuit_parser::builder` and `biscuit_auth::builder`, with a circular-ish dependency (biscuit_auth depends on biscuit parser, but code generated by the `ToTokens` impl blocks in biscuit parser depend on `biscuit_auth::builder`).