Fix deserializing snowflakes from non-self-describing formats

[MurrayGroves]

Previously snowflakes were deserialized using deserialize_any which is recommended against because it prevents usage with non-self-describing formats such as Bincode (which was my use-case which caused me to run up against this issue).

I simply replaced deserialize_any with deserialize_str. Although this causes the deserializer to expect to read a str, the bytes representation of 1234 and "1234" are the same so it works perfectly. All tests pass.

[GnomedDev]

Can a test be added to make sure that this behaviour is preserved into the future?

[MurrayGroves]

Can a test be added to make sure that this behaviour is preserved into the future?

After adding a test I realised this doesn't actually work. After a few hours of investigation it's become clear to me it isn't actually possible to deserialize the IDs without deserialize_any because of the fact it can come from both u64 and string.

[MurrayGroves]

@GnomedDev

What is interesting though is I'm not sure there are any actual cases where you will be deserializing from a u64 and not a string. The Discord API returns Snowflakes as strings in the first place. Additionally the Serialize implementation also serializes as a string, so I wonder if there actually is a need for being able to deserialize from a u64?

[GnomedDev]

We may be deserialising from u64 in config files or other non-Discord sources, which isn't documented but people are going to be relying on. I'd be very reluctant to remove that behavior.

[MurrayGroves]

We may be deserialising from u64 in config files or other non-Discord sources, which isn't documented but people are going to be relying on. I'd be very reluctant to remove that behavior.

That makes sense, will just have to handle deserialisation manually for my usecase I guess.