Separation of Concerns - flutter_rust_bridge

The flutter_rust_bridge_template sets up one Rust source file, api.rs to contain all the Rust interfaces to be exposed to Dart. Before I started coding network traversal, I wanted to break api.rs up, because it already contained build information APIs and QR Code APIs, and I didn't want to additionally dump ICE code in there. I thought `pub use` might be enough to get flutter_rust_bridge to traverse multiple modules, but it wasn't. I turned my attention to the invocation of flutter_rust_bridge. Rather, I figured I could just invoke it multiple times for each set of APIs I wanted. That was the same thinking another user had hashed out in this thread. He even did us all the favor of opening a PR to add support for this workflow. The version I had was already new enough, so I tried it, but the argument name wasn't valid anymore. The thread also contained a link to the CLI reference, and the modern version works a bit differently, where the main arguments can be given multiple times. After experimenting a bit I was able to get it working.

flutter_rust_bridge_codegen \
    --wasm \
    --rust-input native/src/build_info.rs \
    --rust-output native/src/generated_bridge_build_info.rs \
    --dart-output ./lib/generate_bridge_build_info.dart \
    --class-name BuildInfo \
    --rust-input native/src/qrcode.rs \
    --rust-output native/src/genderated_bridge_qrcode.rs \
    --dart-output ./lib/generated_bridge_qrcode.dart \
    --class-name QrCode

However, I wasn't quite satisfied yet. I didn't like that the generated files were alongside the source files, and the Dart linting didn't like it either. The generated files aren't perfect according to the linter, though they work just fine. It would be better if I can move them to their own directories, and exclude those directories from the linter. The generated Dart code was easy to move, and exclude in the linter settings. The rust code was proving to be a little trickier. I learned a little about the module system and figured out that I needed to add a mod.rs to the new subdirectory, and then reference it at the top-level's lib.rs. Everything is squeaky clean now, no more errors or warnings in VS Code's Problems pane.