fix(bindings): omit wit // comments from generated Python docstrings

[cestercian]

Summary

The `bindings` command was putting both wit `//` comments and `///` docs into generated Python docstrings. Filter non-doc comments (`//` / `/* /`) before `wit-parser`, while keeping `///` and `/* */`.

Fixes #177

Test plan

• Unit + bindings integration tests for docstring filtering
• `cargo clippy --lib -- -D warnings`

[dicej]

Thanks, @cestercian.

My initial thought is that we should update wit-parser to distinguish between the two comment types rather than create a separate "comment pre-processor" to work around the current wit-parser limitation. That way, we'll help other component tooling (e.g. wit-bindgen, componentize-go, ComponentizeJS, etc.) make the distinction without needing to redundantly provide their own pre-processors.

Specifically, I'd suggest splitting Token::Comment into e.g. DocComment and NonDocComment variants, updating the Tokenizer to parse them, and modifying the rest of the parser as necessary to ensure only the DocComments contribute to the docs fields in the various wit-parser types (and possibly adding new comments fields for the NonDocComments if that seems useful).

[cestercian]

@dicej agreed. preprocessor was a local workaround; splitting Token::Comment into DocComment / NonDocComment in wit-parser is the right place so wit-bindgen and the others get it too.

i'll open a wasm-tools PR for that and park this componentize-py change until we can drop the filter (or thin it to just consume NonDocComment if the parser surfaces it).

[cestercian]

@dicej upstream PR opened: bytecodealliance/wasm-tools#2670

keeping this componentize-py PR as draft until that lands (or we can depend on a release that has the DocComment split).

[cestercian]

parking this for now — wasm-tools#2670 was closed; maintainers want a Component Model spec change for doc-comment syntax before wit-parser grows a DocComment token. will revisit once that lands (or if we should stick with the preprocessor approach here).