Try explicit registration for foreign macros

[countvajhula]

Summary of Changes

This just implements the define-qi-threadable-syntaxes solution from #16 so we have something concrete to compare against.

Public Domain Dedication

• [x] In contributing, I relinquish any copyright claims on my contribution and freely release it into the public domain in the simple hope that it will provide value.

[countvajhula]

@michaelballantyne The "common function-like interface" sounds promising. In the meantime, how do you feel about merging this in so that we initially -- conservatively -- support explicit registration of foreign macros? That way, when the foreign macros eventually come to take Qi macros' jobs with option (A) from #16 (assuming of course that we do find a solution here, e.g. the function-like interface or "local-expand intermediary" based solution), it would be an extra cool feature rather than a correction of a weird in-between state. I could also create an issue for this so it can be explored independently of the initial macro work since we don't quite know what it involves yet. WDYT?

Also, we didn't have time in the call to get to it, but, in this PR, I manually copy over the threading-side syntax property during in-place macro expansion via syntax-local-apply-transformer, since the right-threading-clause macro puts the syntax property on the entire expression (flow flo), but syntax-local-apply-transformer gets the subexpression flo which doesn't have the property on it. Another possibility would be to apply the property recursively in right-threading-clause so that copying it isn't necessary in Qi macro expansion -- is there an idiomatic way, or do you have any preferences here?