Allow for custom traits

[kaimast]

I took a stab at #5 and added an example. Let me know what you think! I also re-organized the top-level Cargo.toml a little to make examples work correctly.

[decomoraes]

Hello @kaimast, thank you for your contribution. I will check it as soon as possible.

[decomoraes]

Hello @kaimast, Thank you for your pull request. After carefully reviewing the proposed changes, I have concerns regarding backward compatibility. The introduction of a specific type Item would result in breaking changes for existing users of the library. Code relying on the current implementation, which utilizes dyn Any for maximum flexibility, would need to be significantly modified to adapt to the new approach. For instance:

if let Some(string_opt) = value.downcast_ref::<Option<String>>() {
    if let Some(string) = string_opt.as_deref() {
        return Some((key.to_string(), format!("{}", string)));
    }
}

This snippet would no longer work as intended, affecting users' existing code. To preserve backward compatibility while adopting your suggested improvements, I'm considering introducing a new trait, IterableItem, alongside the existing Iterable trait. This way, we avoid breaking changes for current users. Could you adjust your PR to fit this dual-trait approach?

Looking forward to your thoughts.

[kaimast]

Sorry for the delay. Could you take a look at the example I added ("examples/any.rs"). I think what you describe still works.

The only difference is that the generated trait now has an Item field. I can add a separate trait like you suggested, but it would introduce some code duplication.

Also, I would suggest adding basic CI to the repository so that pull requests can be tested. I can make another pull request that adds Github Actions if you want.