Rust SDK: no more reducer args structs

[gefjon]

Description of Changes

Well, at least, the reducer arg structs are no longer user-facing. They're still generated and used internally, for ser/de.

This mostly involves a lot of uninteresting shuffling things around in the codegen. One notable piece is that we must now be more precise about what names are re-exported by the generated mod.rs. The (now-internal) arg structs are pub(super) where super is that mod.rs, but the previous system of emitting pub use foo_reducer::*; would expose it anyways, causing the exact same name conflict that we're trying to avoid here. As such, this commit includes a rework of print_module_reexports which avoids glob reexports for types and reducers. Tables still use glob re-exports,
since reexporting callback ids would otherwise be complicated.

API and ABI breaking changes

Minor incompatible change to the Rust SDK: code which inspects ReducerEvents sees one less layer of nesting. Some patterns may need to be rewritten, but this should be easy.

Expected complexity level and risk

1: this code is well-tested, and the majority of this diff is autogenerated.

Testing

Describe any testing you've done, and any testing you'd like your reviewers to do,
so that you're confident that all the changes work as expected!

• Test suite!
• Private companion & its tests.

[RReverser]

They're still generated and used internally, for ser/de.

Is this because we don't support enum variants with fields in our macros?

[gefjon]

They're still generated and used internally, for ser/de.

Is this because we don't support enum variants with fields in our macros?

There's a few things going on here:

• We can't derive(Serialize, Deserialize) on enum Reducer, for a whole host of reasons.
• Even if we could, or if we implemented those traits manually, the WS format doesn't contain a BSATN-encoded Reducer; it has a dependent pair of (reducer_name: String, args: (reducer_type reducer_name)), where the client has access to a partial function reducer_type : String -> Type.
• This means that what we actually need is to implement reducer_type, and then a way to deserialize each different reducer args on its own. Hypothetically, one could work up construction with DeserializeSeed which does this straight into Reducer without the intermediate per-reducer struct, but that seems like a lot more work for no clear gain.

I will add comments to this effect.