Data migrations with Julia functions on attributes

[KevinDCarlson]

This PR upgrades the @migration macros with the ability to plug Julia code into appropriate locations. For instance:

• If a is an attribute of the target schema, one can write a=> x->body, where body may depend on x and all the names in the source schema. This allows the produced migration to mutate the attributes in a more-or-less arbitrary way. The generality of this mutation is illustrated in the tests by TuringMachine.
• Similarly, if h is a hom in the target schema, we can write h's image in terms of an anonymous function whose value depends on all the names in the source schema, but one whose values will be combinatorial data rather than attribute values.
• More generally, the above hold when a hom or an attribute is sent to a multi-line diagram hom, for each line of that hom independently.
• If an object of the target schema is sent to a conjunctive diagram, this diagram may include morphisms over expressions of the same form as in the previous bullet, allowing the migration to effectively filter the migrated acset via arbitrary code applied to its attributes.
• When an attribute a of the target schema has as domain an object sent to a conjunctive diagram containing an object y, we may write a=> (b(y)|>(x->body)) to disambiguate the input.
• The single-line -> expressions can be replaced with blocks whose last line is such an expression.

The behavior is basically that the macro builds a DataMigration superficially just as it used to, but where some values of the hom_map of the underlying functor may be AttrExpr{:nothing}, and those and perhaps other homs have their values modified upon actually migrated using the Julia functions stored in the migration's params.

The most immediate remaining concern is that the code relies on changes in lots of places, at all three of the key steps of the migration macros (parsing into values from DiagrammaticPrograms.AST, then into actual Diagrams and DiagramHoms, then doing the actual migration), while also allowing for several different syntaxes, and so is not so clean.

The biggest large-scale concern is that we can't yet use multi-input Julia functions, as for instance you'd want to take a product of weighted graphs with the weights of a pair of edges given by the sum of the pair's member's weights. This is an actual semantic step beyond the model we've used so far, as the intermediate migration of something like weight => (x,y) -> weight(x)+weight(y) would need to send Weight to Tuple{Weight,Weight} or to @cases W:Weight; U:Weight, and this splitting would need to be collapsed upon the actual migration. None of this shifting of attribute types happens with examples we can do up till now. The Tuple solution seems easiest, but it does lead to the question of what happens if you have two different combinatorial types using the same attribute type a different number of times each. So I don't think there's an obvious choice of direction here.

[epatters]

Thanks Kevin, this will be an awesome feature. First round of comments below.

[epatters]

Thanks Kevin! Here's a batch of small questions/comments. I'll pick up with more reviewing later but I wanted to get some stuff down now.

[epatters]

OK, with this round of comments I am through the code itself! Now I just need to go through the tests.

[epatters]

Final round of comments on the tests.

[KevinDCarlson]

Ready for re-review (!!!!!)

I should note that there aren't any tests for aggregation and such unintended applications yet.