fix: support qualified types in topic handlers

[immanuwell]

Description

#[topic] blows up if the handler arg uses a qualified type like serde_json::Value.

The macro was splitting tokens on : so serde_json::Value got treated like 2 inputs. This switches it to parse the function signature with syn, keeps the String fast path, and adds regression tests. tiny fix, but pretty real.

Repro:

#[topic(pub_sub_name = "pubsub", topic = "A")]
async fn handle_a_event(order: serde_json::Value) {}

Before:
cargo check panics with Expected to only have one input variable

After:
cargo check passes.

Issue reference

This PR will close #172

Checklist

• Code compiles correctly
• Created/updated tests
• Extended the documentation

[mikeee]

I'm in favour of this change with a few changes, please could you clarify whether allowing non-stdlib definitions of String should be allowed as implemented?
I think for the string type assertion it'd be better if we asserted against the entire type path, something like this:

fn is_string_type(ty: &Type) -> bool {
    let Type::Path(type_path) = ty else {
        return false;
    };
    if type_path.qself.is_some() {
        return false;
    }

    let path = &type_path.path;
    let matches_path = |names: &[&str]| {
        path.segments.len() == names.len()
            && path
                .segments
                .iter()
                .zip(names)
                .all(|(seg, name)| seg.ident == *name && seg.arguments.is_empty())
    };

    matches_path(&["String"])
        || matches_path(&["std", "string", "String"])
        || matches_path(&["alloc", "string", "String"])
}

wdyt?

[mikeee]

Was this intentionally added to allow String types defined by any other crates such as other_crate::String?

[mikeee]

Thank you for adding tests, please enhance this with negative tests to confirm the above review assumptions.