create_application_commands can now take any IntoIterator: not just &[]

[zkxs]

This is a small change: currently poise::builtins::create_application_commands takes a &[crate::Command<U, E>]. This PR changes it to take an IntoIterator<Item=&crate::Command<U, E>>. This doesn't really change much, except it makes the API slightly easier to work with if API users don't simply have a Vec<Command<U, E> lying around: for example if you're dynamically computing which commands should be set on a guild-by-guild basis.

[GnomedDev]

This is a breaking change, therefore needs to be targeted at the next branch.

[zkxs]

@GnomedDev after some confusion between the serenity-next and next branches I've changed the base.

[GnomedDev]

Do you want to also update the functions that call create_application_commands to take advantage of the more permissive function signature?

[zkxs]

Sure; it should be done now unless I missed any: it looks like it's just register_in_guild and register_globally.

[GnomedDev]

Ignore the clippy issues, they are failing for unrelated issues, while you fix the rustfmt issue could you use Iterator::size_hint to restore the Vec::with_capacity optimization?

[zkxs]

@GnomedDev Should be done. I'm not checking the upper bound on size_hint, but that seems correct to me because in my experience overestimating the allocation tends to hurt performance more than underestimating.